-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Auth - OAuth2 (Dovecot PassDB) #3480
Conversation
I'll possibly be able to contribute feedback / review sometime this month. The other maintainers are also a bit busy, so just a heads-up if it takes a bit of time 😅 (I've got a bit of a backlog to address first in DMS and elsewhere) |
I'm realising that there is really no way to solely use oauth2 if you also want to use any generic imap client like thunderbird or almost everything on mobile. I'm aware this was mentioned in the original issue. Essentially this is just an update comment saying that I'm looking into proxying passwords to the auth backend. Unfortunately it doesn't look promising as grant password has been deprecated... although there might be some light at the end of the tunnel. Until the next update o7 |
Hey sorry for the silence about this, caught up working elsewhere on the project. While working with the LDAP support, I have been wondering if the OAuth2 / OIDC support is meant to be an account provisioner or just an alternative authentication feature DMS could support? Probably nothing below that you don't already know; However, I am forgetful this is more of a refresher for me when I return to this 😝 I don't have time to go over the existing discussion for the feature or this PR right now, but flow wise we have:
With the current LDAP and FILE provisioners, both auth and accounts are configured to use that provisioner.
From what I understand, the OAuth2 backend may be sufficient if mail clients are restricted to being compatible with that, however some deployments may want to support traditional means. Some IDPs like Keycloak can support both OIDC and LDAP IIRC, which should allow centralizing the account management/provisioning through that service, as you don't really want to try keep two different account sources in sync (eg: static) 😅 Thus DMS probably needs to rethink the account management support, refactoring how we configure Dovecot PassDB/UserDB? I can try give that some thought after I bring LDAP support into better shape. |
Good consolidation, yeah. Most of that rings true, I have some ideas but life has caught up with me and I'll be busy for a while. I'll keep an eye out for mentions here in case others want some help taking over if I'm not back to finish this soon. |
Thank you for this PR. I am wondering if using LDAP in this case will keep working with OIDC? Because you mentioned that the standard long is not working anymore. |
The thing stopping oAuth2 from being it's own fully blown auth provider is that lack of query-ability. As such, for now it will likely just be a layer over top for something like roundcube to make use of, but still falling back to something like LDAP. I'm thinking of just reducing the scope of this PR to that for now and creating another for the final form; The final form being implementing adapters for different oAuth2 provider APIs such as Authentik, KeyCloak, etc. to allow user querying. This would allow for oAuth2 to be its own fully blown auth provider. |
Being its own fully OAuth2 provider and falling back to other providers like LDAP is the best solution and so should it be, IMO. Is there any time estimation when you will working on it? |
I have some time this weekend, hopefully to get the minimum use case done in this PR. |
Great! I am excited! Let me know if I can somehow support. |
The comment here is interesting: Would this change the way you are going to implement this PR? It just attracted my attention, because it is talking about the most modern way of authenticating E-Mail users. @polarathene could you please also take a look on it? |
I don't know what you want me to take from that. I don't see it adding anything helpful to the discussion here.
You would provision accounts and have same auth as we do currently AFAIK. This PR will provide an alternative authentication mechanism. There is another PR contributing Dovecot auth via Lua scripts as another alternative (but won't be officially supported by DMS, only via a community guide in the docs), it's been discussed there that in future DMS may need to rework this support to better separate the account provisioning choice and enabled auth backends for Dovecot to use. It may be a couple months before I have time to spare for any of this. Backlog is already full. |
224bbc9
to
80dced8
Compare
I'd agree with @polarathene, that doesn't really change the situation. For now it's just going to be enabling oauth2 in dovecot as an alternate login method allowing for things like SSO webmail login. The Lua scripts sound ideal for the potential next phase of this implementation which is to make oAuth2 a full blown auth provider. They would be used to retrieve user lists for mailbox creation etc. |
It's been a while since I looked into OAuth / OIDC, but I remember OIDC resolving that issue (or it may have been OAuth2?). I do recall before that I would see different libraries for languages that would maintain a massive list of OAuth provider integration, but AFAIK that became much simpler with OIDC (OpenID Connect). Perhaps one option is to add a bridge of sorts that provides the OAuth2 providers if needed, but ideally OIDC if that has good compatibility these days, then for integrating with Dovecot I suppose it might be possible to route the OAuth2 feature through that internal DMS service? 🤔 I've not worked on such myself before, so it may be too much work as-is. I assume Dovecots mention of a Proxy Backend for OAuth2 might be related to this for offloading the auth to a separate service / container. If it's easier taking the per provider route, then this would be less valuable to DMS and might be better suited similarly to the Lua support via our docs? We can add some integration and some provider support, but rather than DMS maintaining providers it may be better as a BYO guide from the docs? 🤷♂️ That way the community can contribute provider support more easily and the providers that DMS users express enough interest in can be part of DMS. EDIT: I assume this is about the Dovecot OAuth2 "Backends" examples? EDIT: Here's an old discussion about using KeyCloak for the OIDC service to connect with any other services, and Dovecot integration (which has some interesting information about their implementation). KeyCloak would be too big for DMS to bundle, so they'd need to use a separate image, but I believe there are some Go or Rust based projects that might be an option if there is any benefit bundling such a service into DMS. I may have misunderstood that interaction and it changes nothing to the Dovecot OAuth2 provider issue 😅 UPDATE: Oh, there is already OIDC support in Dovecot? 🤔
|
Ok I have this working as of now with authentik and roundcube. The user has to exist beforehand in dms for it to work as we are not providing dovecot a userdb, only a passdb. Ergo, either ldap or file provisioner must be used and the user added beforehand. @MohammedNoureldin can you confirm this before I add tests and document?
and a roundcube configuration reference can be found here |
Sounds great! Thank you!
Should this be the case? I mean, in case of LDAP, we are also not storing anything related to the user, but rather fetching the data directly from the LDAP server, and the mails are accordingly stored in the folder of the user. Why can't this be the case with OIDC? I mean it should be somehow possible to log in to the mail also for the first time. Or did I misunderstood the point here? |
LDAP service has the account information already, including mail specific data such as aliases for that user. Postfix and Dovecot talks to the LDAP service to retrieve this information.
That is a folder Dovecot manages responsibility for, nothing to do with LDAP. To accept the mail, the account must exist from the provisioner. Dovecot UserDB provides that information, which for LDAP involves talking to the LDAP service to verify IIRC.
You can authenticate with Dovecot via the PassDB, this then optionally provides some information to UserDB IIRC. Even if that works fine, if you have not logged in, then how should Dovecot handle the situation when Postfix provides some new mail for the account? Dovecot needs to know it exists to accept the mail, so how will it check via UserDB? OIDC is just providing authentication AFAIK. Dovecot needs to know not only if a user exists, but any additional information such as mail storage location, quota limit, etc. Many of these we can provide defaults on. I know that OIDC allows supporting some complimentary user data, but not sure if it's that flexible for the Dovecot related user data. LDAP support has Dovecot perform a lookup query to the LDAP service, usually with an admin account or similar permissions to grant querying user data. LDAP also supports auth (PassDB), like our file provisioner. But AFAIK OIDC is only able to support the PassDB functionality, not UserDB, hence why you need something else providing that data to Dovecot. |
b24096d
Please excuse my delay. I had some private circumstances and thus I could not do any progress. Now I available again and would be very glad to help! I see that you made a lot of progress here. Well done guys! Please let me know if I can support somehow. |
You can give it a try if you like. Let me know if you run into any problems, like the docs not providing enough information to setup for you. How important the ENV ( This feature is otherwise approved and will get merged for v14 🎉 One concern that might be worth raising awareness on is with this integration, if your third-party auth provider let's you configure the Usually there should be additional information like Non-issue if the auth service is self-hosted and this sort of account registration concern isn't applicable. |
Documentation preview for this PR is ready! 🎉 Built with commit: acfc44d |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving and merging for v14.
If I have time to revise an update to the oauth2 docs / ENV before then, I will but at this stage I may not have the time for it :(
Thanks for contributing this new feature! ❤️
Thanks guys. I have been trying to get it working with NextCloud, still I have some points to clarify. Just one point regarding its release, this is a sensitive feature, I would release it in a separate minor version (13.3.0) ASAP and mention that it is under review rather than major version with many other big changes. What do you think? |
Why is it sensitive? You need to opt-in regardless.
Unfortunately our release process isn't well suited for that if we've already merged changes that would be semver incompatible:
Thus once breaking changes are added to Looking at the current We have improved our review process to add changelog entries before merging now, so much of that friction to releases is now gone 💪
Presently the only big change due for v14 is the base image upgrade from Debian Bullseye to Debian Bookworm, and all the package updates that brings. I would like to get the LDAP breaking change in as well, and I may be able to get that resolved in time. Other than that, I don't think we have anything else that should be breaking / big.
It would be good to get v13.3 out for the I'm comfortable with v13.3 if the other maintainers are too. |
I think the Rspamd changes are not breaking as we define it. I'm fine with releasing v13.3. UPDATE: ref #3781 |
@polarathene thank you for the explanation. I said sensitive because it is about authentication in general, which is the first part the user need to be able to interact with the email. And thus any small issue may potentially end up that users are not being able to login, for example. That is why it seemed sensitive to me. @georglauterbach thanks for confirming this! This sounds great, so we can soon have this in 13.3.0. |
Fair. In that case do you want the breaking changes LDAP PR to be it's own major release instead of bundled with the base image upgrade? |
I'd prefer to have it in one release; less work on our side 🤣 |
I think the reasoning was the release separation benefits maintainers too when it comes to troubleshooting issues related to releases that introduced breaking changes. The LDAP changes are large enough that it'd be easier to troubleshoot when you rule out the changes the base image upgrade PR introduces. Thus the separate releases is probably less work maintenance wise 😝 |
I am neutral here :D you can decide whether you would like to put them in one or two PRs. Actually I have been trying to test, but for some reason I am not able to login even using LDAP, it is not related to this change as I am trying with 12.1.0. I get dovecot: auth error failed operations error. I will keep trying for a few hours yet, maybe I can get it working. Otherwise I will open a discussion asking for help ^^". |
Set
Are you saying you cannot login with LDAP? Nothing should have changed there and our tests pass auth: docker-mailserver/test/tests/serial/mail_with_ldap.bats Lines 378 to 384 in 2bf5234
It's possibly related to your LDAP config and DMS related settings for query filters (and docker-mailserver/test/tests/serial/mail_with_ldap.bats Lines 74 to 90 in 2bf5234
I've already verified that this feature is compatible with our LDAP auth tests, so I know it works :) The LDAP config will be changed and the related docs page completely rewritten to accommodate it. Another change will affect SASLAuthd LDAP integration with Postfix as I'm not happy with it introducing an inconsistency. As this is getting offtopic, feel free to open an issue/discussion when you have more information to share and ping me there 👍 |
I see, makes sense. Then let's please merge #3403 first because I really want to finally have Debian 12 (to change some things in my personal setup). |
I have no clue anymore. I am not able to test this because, as mentioned, for some reason I cannot connect to LDAP anymore, which really frustrating after 20 hours of trying. I tested also 12.1.0, so it is not related to the changes made here. Though, any help would be great so I can do extensive test to this feature. To keep this PR clean I opened a new discussion for it. https://github.com/orgs/docker-mailserver/discussions/3785 |
As an update, after a lot of tests I was NOT able to get it working with NextCloud. However, it turned out (I got an official statement regarding this), that Nextcloud Mail does not forward the access tokens apparently the the mail server. So I stopped working on it at the moment. |
Description
I decided to start on an implementation of Oauth2 as described in #2713.
I am testing this locally with my Authentik instance and a roundcube instance configured as per their documentation.
Original details prior to PR feedback
I'm setting the following new variables as such:
The current oauth2 login (that's all I've done so far) accepts xoauth2 tokens from something like roundcube using the dovecot passdb xoauth2 mechanism.
login
orplain
despite the fact that the configuration allows it and so all email clients that don't support generic oauth cannot login.With the current changes, I am able to:
Implementation TODOs
Questions
Out of the 3 options listed in the tracking issue regarding account provisioning, which is going to be the best solution?
The first option is implemented here, using a static userdb.
The third option sounds like it would be the optimal one however there have been points made against this.
Type of change
PR Checklist:
docs/
)