WebSSO - Webmail with SAML or OIDC | MDaemon Technologies Community Forum
  1. Forum
  2. MDaemon
  3. WebSSO - Webmail with SAML or OIDC

WebSSO - Webmail with SAML or OIDC

  • A

    Hi Arron,

    Thank you for your quick response.

    Regarding the proxy part: my IDP is LemonLDAP::NG, which serves as both my IDP and my Nginx reverse proxy. Since it is open-source and a versatile tool, it allows me to monitor all traffic through the logs. I have made some progress and have some specific information to share with you:

    From the logs: https://connect.<mydomain.fr>/oauth2/authorize?response_type=code&scope=openid%20profile%20email&client_id=OpenIDMdaemon&state=07596abaca431d8cd18b7007a2846e85&nonce=103deca5c478401d4353ff18d77ba4d6&response_mode=form_post&redirect_uri=https%3A%2F%2Fmail.<mydomain.fr>%2FWorldClient.dll%3FView%3DOIDC

    As you can see, the redirect_uri is indeed pointing to mail.<mydomain.fr>. Consequently, I cannot use https://webmail.<mydomain.fr>/WorldClient.dll?View=OIDC as you suggested.

    In the MDaemon configuration, this field is greyed out, so I am currently stuck.

    My other option would have been to publish the webmail behind the mail.<mydomain.fr> URL instead of webmail.<mydomain.fr>, but unfortunately, that is not possible. For security reasons, our architecture requires SMTP (mail.<mydomain.fr) and HTTPS (webmail.<mydomain.fr>) traffic to pass through two different public IP addresses.

    The solution would be to either "un-grey" this field so I can specify it manually, or to modify this value directly in an MDaemon configuration file, rather than having it automatically generated as https://<SMTP Host Name>/WorldClient.dll?View=OIDC.

    What are your thoughts on this?

    0 likes
  • A

    If your provider is responding and saying that the redirect URI is https://mail.yourdomain.fr/WorldClient.dll?View=OIDC then its because that is what has been configured in the provider.  You should be able to change it in the provider conifgurations.

    The value shown in the MDAemon UI is just there to assist customers in figuring out what value should be. It is not a configuration that is being used by webmail.

    In addition, the redirect URI configured in your provider needs to use the same host name that is being used to access webmail.    So if you are accessing webmail using https://webmail.mydomain.com then the redirect URI that you configure in the provider should be https://webmail.mydomain.com/WorldClient.dll?View=OIDC.

     

    --
    Arron Caruth

    0 likes
  • A

    Hi Arron,

    Please excuse the delay in my response; I was off for the past few days.

    I have configured the correct URL on my IdP. The log I sent you was captured from my reverse proxy, showing the response returned by MDaemon.

    I would like to share some screenshots with you, but I would prefer to send them privately. Is there a way for me to do this, and if so, how should I proceed?

    Thank you, and have a great day!

    0 likes
  • A

    I'm sorry, I provided incorrect information about the Redirect URI previously. 

    During the beta cycle we were using the value in the host header provided by the browser to build the Redirect URI, but we updated it prior to the release of MDaemon 26.0.0 to use the Default Web Address for MDaemon Webmail or if that is blank it will use the FQDN configured for the server. 

    To set the Default Web Address for MDaemon Webmail login to Remote Administration and go to Main | Webmail Settings.  Enter the desired host name, save the changes and restart webmail.

    The example value provided in the user interface does not change when you update the Default Web Address for MDaemon Webmail.  I've added a task to update the UI to show the preferred value, based on the setting.

    Again, my apologies for the incorrect information.  Let us know if you are still having issues after making the change.

    --
    Arron Caruth

    0 likes
  • A

    Hi Arron,

    Thank you very much for your help. It works like a charm.

    Have a nice day,

    0 likes
  • M

    Hello,

    We are currently testing OpenID Connect authentication with MDaemon Webmail 26.0.1 and Keycloak as the Identity Provider.

    Our architecture is the following:

    MDaemon Webmail
    ↓ OIDC
Keycloak
    ↓
Nginx reverse proxy

    We have identified an issue that appears to be related to TLS negotiation when the following Nginx directives are enabled:

    ssl_client_certificate /certs/root.pem;
ssl_verify_client optional;

    These settings are required in our environment because we use client certificate authentication for other applications behind the same reverse proxy.

    Symptoms:

    • MDaemon fails to retrieve the OIDC configuration from the .well-known/openid-configuration endpoint.
    • OIDC configuration and authentication fail.
    • The same URL is accessible without any problem from a web browser running on the MDaemon server.
    • Using PowerShell Invoke-WebRequest also succeeds.
    • Using curl with Schannel shows TLS renegotiation requests from the server:
    schannel: remote party requests renegotiation
schannel: renegotiating SSL/TLS connection
schannel: SSL/TLS connection renegotiated

    Most importantly:

    • As soon as we disable the following directives:
    ssl_client_certificate /certs/root.pem;
ssl_verify_client optional;

    MDaemon is immediately able to retrieve the OIDC configuration and authentication works correctly.

    This makes us suspect that MDaemon may have difficulties handling TLS connections when the server requests an optional client certificate during the TLS handshake.

    Has anyone experienced a similar issue with OIDC providers behind Nginx using:

    ssl_verify_client optional;

    or mutual TLS configurations?

    Are there any known limitations in MDaemon's OIDC implementation regarding TLS renegotiation or optional client certificate requests?

    Any advice or recommended architecture would be greatly appreciated.

    Best regards,

    0 likes
  • A

    A quick analysis shows that WinHTTP is not handling the request for a client certificate correctly.  The only workaround is the one that you found, to disable ssl_verify_client optional;.

    I've submitted a bug for the development team to investigate further.

    --
    Arron Caruth

    0 likes
  • M

    Thank you for your investigation and for submitting a bug report.

    We appreciate your help and hope a fix will be available soon, as it would greatly simplify our deployment.

    Best regards,

    0 likes
  • M

    While we are discussing OIDC integration, we would also like to know if there are any plans to provide a direct SSO login URL for MDaemon Webmail.

    Our goal would be to place such a link on our intranet portal, allowing users who are already authenticated through our identity provider to access their MDaemon mailbox seamlessly, without having to first reach the Webmail login page and click the "Sign in with SSO" button.

    Could you please let us know if such a feature already exists or is planned for a future release?

    Thank you.

    0 likes
  • A

    My apologies, my first response was wrong.  

    There is actually a direct SSO login URL for webmail.

    https://<your-webmail-host>/WorldClient.dll?View=Main&SignInWithSSO=Yes

    The user must already be authenticated with the identity provider and HTTPS must be used.  

     

    --
    Arron Caruth

    0 likes
  • M

    Thank you for the clarification.

    We tested the URL and can confirm that it works correctly.

    This is exactly what we needed for our intranet portal integration.

    While we are discussing SSO features, we would also like to mention a future enhancement that would be very valuable for our organization. It would be helpful to have the ability to enforce SSO-only authentication for selected accounts, preventing users from authenticating with a local MDaemon password.

    Our long-term goal is to avoid maintaining two separate password systems and rely exclusively on our identity provider for authentication. If such a feature could be considered for a future release, it would greatly simplify our administration and security management.

    Best regards,

    0 likes
  • A

    It would be helpful to have the ability to enforce SSO-only authentication for selected accounts, preventing users from authenticating with a local MDaemon password.

    Can't this already be accomplished by just not telling user's their password for the local MDaemon account? 

     

    --
    Arron Caruth

    0 likes
  • M

    The goal would be to ensure that SSO is the only available authentication path, using a centralized multi-factor authentication process that is consistent across all of our applications.

    Today, local MDaemon authentication still represents an alternative entry point. Even if that door is effectively "locked" within our organization (because users are not given their local passwords), it remains technically available and could potentially bypass security controls enforced by our Identity Provider, such as MFA, conditional access policies, centralized auditing, and account lifecycle management.

    We would therefore like the ability to enforce SSO-only authentication, either for selected accounts or for an entire domain.

    For example, under Account Settings > Web Services, an option such as:

    ☑ Enable Webmail access
    ☑ Allow SSO authentication only

    or

    ☑ Enable Webmail access
    ☑ Disable local password authentication

    would ensure that all Webmail access is routed through the Identity Provider and benefits from the same security, compliance, and access control policies as the rest of the organization's applications.

    In any case, thank you for your assistance and for taking the time to consider our request. We truly appreciate your support and willingness to listen to customer feedback.

    Best regards,

    0 likes
  • A

    Thanks for the feedback, we'll consider it for future versions.

    --
    Arron Caruth

    0 likes
  • 1
  • 2 / 2
Please login to reply to this topic!

Participants