Request for Feedback: SSO and LDAP

[cromulus]

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: 1) install and configure ldap locally, the default. 2) point to a remote LDAP server

Thoughts?

[JoshData]

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.

[cromulus]

Thanks.

I’ll hold off submitting a PR until well after 18.04.

[arodier]

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]

adding for future reference: SHA512 password strings in LDAP

[rissson]

@cromulus Any news on that feature? It's something I would really want to use with mailinabox!

[cromulus]

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!

[JoshData]

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.

[downtownallday]

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.

[downtownallday]

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.

[cromulus]

@downtownallday care to share your changes? I’d love to see what you’ve built and try it out! Thanks!

[ghost]

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]

@downtownallday care to share your changes? I’d love to see what you’ve built and try it out! Thanks!

Sure

[downtownallday]

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."

[ghost]

@downtownallday Any chance you can upload the LUKS wrapper? Maybe as a gist?

[cromulus]

@downtownallday this is very exciting!

@JoshData what do you think?

[hungrymonkey]

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

[cromulus]

@hungrymonkey I think this is how: https://help.github.com/en/github/receiving-notifications-about-activity-on-github/subscribing-to-and-unsubscribing-from-notifications

[cromulus]

@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.

[JoshData]

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. :)

[cromulus]

Really quick pass:

1. 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)
2. 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.

[hungrymonkey]

@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))

[cromulus]

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

[snoweuph]

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

[JoshData]

I really can't foresee accepting this. It would be a big change with no upside for most users.

[snoweuph]

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 ?