mailinabox
mailinabox copied to clipboard
mail-in-a-box
Request for Feedback: SSO and LDAP
Hi! If I were to whip up single sign on and LDAP, @JoshData, would you be willing to merge it in?
I'd likely use YunoHost's SSOwat for the single sign on. It's small, lightweight, integrates into nginx and LDAP, YunoHost is reasonably mature, and this seems to be a core functionality so I'm confident it will continue to be supported. Additionally, YunoHost has already built the sso integrations for two of the user facing applications: roundcube and nextcloud
Their methodology is similar to ours: patch config files.
As for ldap, I'd likely use the standard openldap server with two options at installation:
- install and configure ldap locally, the default.
- point to a remote LDAP server
Thoughts?
I'm probably not going to have time to review any new feature. The only things I'm likely to have time for are addressing existing critical problems and figuring out how to move to Ubuntu 18.04 when it's released.
Hello Josh et al,
If this can help, I have started to publish and improved the scripts I used to deploy my personal mail server at home. I always used LDAP for SSO.
The whole installation is automated through Ansible, but the LDAP part is easy: https://github.com/progmaticltd/homebox/blob/dev-arodier/install/playbooks/roles/ldap/tasks/main.yml
Perhaps I will add a reference to your project in my readme file, this is a fantastic work.
Any question welcome.
@cromulus Any news on that feature? It's something I would really want to use with mailinabox!
I haven’t had the time, nor will until well after March. Additionally, I’d really want the go-ahead from @joshdata before digging in.
That said, now that mailinabox has been upgraded to work on 18.04, I think the time is ripe. The biggest challenge, afaik, is going to be ensuring that we can safely migrate pre-existing, multi-domain hosts from the current SQLite setup to ldap. The second is providing a seamless UI both for installation and management that makes it unnecessary for users to even know that it’s ldap under the covers unless they are advanced enough to be able to fix things themselves.
Both are non-trivial, and I know this project is loath to add more complexity.
That said I also feel like this project, and please correct me if I am wrong, is keen to use the standard tools for the job and not try to reinvent the wheel, i.e. postfix, nginx, etc. SQLite is battle hardened and a Swiss Army knife, but it is not a user management platform.
I’d love to use ldap because I would like to have a central, standards based source of identity/authorization which other apps outside of the mailinabox scope can utilize.
As always, feel free to take a stab at it yourself and I’ll try to help out when I can!
Even though the 18.04 work is done, I'm still not likely to accept any big feature changes --- I don't think it's in line with project goals and I don't have time to be the maintainer of a more complicated application.
Any change of heart on this? I added this functionality but I guess there isn't much point if it's not in line with the project goals. It does fit nicely with Nextcloud 17, which includes user-ldap by default (https://nextcloud.com/usermanagement). I can understand the reluctance to taking on additional change given the time commitment, but in my opinion there does seem to be some synergy here that if not acted on could drive users to other solutions.
FWIW, I've been running with these changes for a short while and it has been working well. I did add a test runner and 30+ automated tests to help validate the changes. And there are quite a few as all sqlite user data is moved to OpenLDAP including passwords, aliases, permitted-senders and privileges with postfix, dovecot, roundcube and management setup/code all reworked. Tangentially, I also added policyd-spf to postfix because I discovered while testing that MiaB is not doing SPF enforcement (but does add spf dns TXT records). Isn't this like saying please enforce our SPF policy, but we're not going to enforce yours? Anyway, my efforts also include hooking up to a remote Nextcloud. After adding a firewall rule to open the ldaps/636 port to Nextcloud and configuring user_ldap (with an "integrate_miab.sh" script), I see all MiaB users and groups (aliases) in Nextcloud and can log in using MiaB credentials.
As part of this effort, I also added a wrapper for disk encryption. Because mail messages often contain sensitive personal information and because the terms of cloud providers like Linode require that you agree to allowing your data to be moved across borders and be retained even after you shut down their services, I added a wrapper to "setup/start.sh" called "start-encrypted.sh" that creates a LUKS encrypted disk (a file) and mounts it at /home/user-data so that all user-data is disk-encrypted. The wrapper disables dependent services and requires that you to log in after a reboot to run a startup script that re-mounts the disk interactively asking for the disk's encryption passphrase, then starts all the services that depend on user-data.
I'm happy to contribute all this stuff, or just keep it to myself if the project is happy where it is.
@downtownallday care to share your changes? I’d love to see what you’ve built and try it out! Thanks!
that creates a LUKS encrypted disk (a file) and mounts it at /home/user-data so that all user-data is disk-encrypted.
Interesting. Although this won't protect the data while it's unencrypted, correct? LUKS is mainly useful while the system is powered down. For mail, you could use a GPG mailgate that encrypts the mail at rest and only decrypts it while you're reading it. As long as your private key is not on the VPS itself, you should be fine.
@downtownallday care to share your changes? I’d love to see what you’ve built and try it out! Thanks!
Sure
that creates a LUKS encrypted disk (a file) and mounts it at /home/user-data so that all user-data is disk-encrypted.
Interesting. Although this won't protect the data while it's unencrypted, correct? LUKS is mainly useful while the system is powered down. For mail, you could use a GPG mailgate that encrypts the mail at rest and only decrypts it while you're reading it. As long as your private key is not on the VPS itself, you should be fine.
I'm not familiar with GPG mailgate, but the LUKS data is encrypted until it's accessed (where the kernel driver decrypts/encrypts it on-the-fly). Encryption-at-rest. Once mounted, you need a login to system to potentially access all the data (within the normal access control restrictions of unix). To do better, IMO, you'd need something like what ProtonMail is doing, where all the encryption/decryption occurs at the endpoint (in the browser). This is more in line with a full "dapp."
Opps. Can somebody tell me how to disable notifications to github when ever a commit references an issue? I want to avoid this situation. This notification bring nothing to the table.
@cromulus , I do not think the doc is correct because it talks about notification sent to me. I kinda want to avoid sending notifications to the issue page. Oh well, I will edit the commit message and remove the issue reference
@hungrymonkey I think this is how: https://help.github.com/en/github/receiving-notifications-about-activity-on-github/subscribing-to-and-unsubscribing-from-notifications
@JoshData I know how you want fewer components rather than more, but in my humble opinion, using standard systems in concert with each other is better than rolling our own.
LDAP is the standard for how to manage users. I think the benefits of using a standard user management system outweigh the costs: all of the services we use, round cube, courier, postfix, dovecot, next cloud, all of them have standard LDAP connectors. Less custom code to maintain.
Just my $0.02.
Less custom code to maintain.
I would challenge you to find some code in Mail-in-a-Box that adding LDAP would allow us delete. :)
Really quick pass:
- LDAP is a first class user management/authentication platform for Nextcloud. Means all of the external user stuff gets dropped. (Though this implementation doesn't change nextcloud auth)
- all of the custom SQL in mail-user.sh
More importantly, the new code is fairly standard: courier, postfix, dovecot, nextcloud are all designed to authenticate against LDAP, not sqlite.
Also, the hungrymonkey, downtownallday code is fairly well tested.
@cromulus , Please do not look at my branch as new development. I only forked the code because something might happen to downtownallday's account and I wanted a copy.
If you want to integrate into a keycloak server, here are a few values you can use.
I think 389 is unencrypted, but I think 636 uses ssl/ldaps
| Settings | Value |
|---|---|
| Edit Mode | Read Only |
| Username LDAP attribute | cn |
| RDN LDAP attribute | cn |
| UUID LDAP attribute | entryUUID |
| User Object Classes | inetOrgPerson, organizationalPerson |
| Connection URL | ldaps://box.domain.com/ |
| Users DN | ou=Users,dc=mailinabox |
| Bind Type | Simple |
| Bind DN | cn=admin,dc=mailinabox (Any Bind DN) |
| Bind Credential | Located in /home/user-data/ldap/miab_ldap.conf |
| Custom LDAP Filter | (&(objectClass=mailUser)) |
Just leaving this here for when I have the time to try to pull this all together:
Identity aware proxy: https://github.com/gnur/tobab/
It allows you to connect one or more identity providers (currently, only google is supported) and grant access to backends based on the identity of the user.
Another option in the same vein: https://github.com/pomerium/pomerium
Ik, this is basicly a dead Issue, but I would love to see this:
point to a remote LDAP server
Im switching up all my selvhosted software to connect to my nextcloud as SSO provider
I really can't foresee accepting this. It would be a big change with no upside for most users.
I really can't foresee accepting this. It would be a big change with no upside for most users.
so what would be the idiots way, of getting SSO ability for their MiaB ?
Some years passed and by now I would suggest to leapfrog LDAP and implement real single-sign-on. That would mean delegating the authentication of all components to an IDP (identity provider).
- standing on the shoulders of a standard software that is specialized in handling credentials (keycloak, authentik,..)
- the applications never get in touch with passwords again and instead implement standard SAML or OIDC
- all user management (create user, change password, manage mfa tokens) is handled by the IDP
- it is relatively easy to connect to an external IDP and use the accounts users already created for other systems. and it would be easy to connect additional applications to use your mail-in-a-box userbase.
- users really only need to login once and the session is valid for all apps -> single-sign-on
- the user-experience (login window) is identical everywhere
- we can tell users that the only place they should ever enter their password is
identityserver.mydomain.tld. (and they can set that in their password manager)
It seems like the components of MiaB (dovecot and postfix, roundcube, multiple Nextcloud OIDC Apps) have the necessary support already.
Caveats (or reasons why it could make sense to wait some more)
- Thunderbird does support OAuth2 but for reasons it doesn't work for selfhosters yet. (issue)
- the same is true for k-9 mail and probably many other clients.
Using an IDP and querying it via LDAP would of course be a step into the right direction.
