This is to carry out the thread I hijacked ( Quotas Implementation - #29 by murgero ).
Basically, it would be nice to have users sign in ONCE, and have them signed into all other applications used in an organization (or group of applications a group of people use).
Hey, @joshua any applications that you would suggest that manage users? Maybe we can have an application run the user authentication/registration, and have MIAB piggyback off that, instead of MIAB doing their own solution.
It’s possible to replace the login mechanism used for all of Mail-in-a-Box’s services, but because most of the logins aren’t web based (IMAP, etc) I don’t think there’s a useful way to do this.
What does MailInABox use now? SQLite? Why not try to implement OpenLDAP?
@JoshData, If I remember correctly, Mail-in-a-Box uses the SQLite file directly from the control panel and Dovecot. Then Nextcloud uses Dovecot through IMAP protocol to login users with Nextcloud.
So all we need to do is change the control panel a little bit to implement something like OpenLDAP (or other solution) and configure Dovecot to use that solution, and all services will work. Thunderbird (or other mail user agents) will contact Dovecot, and Dovecot will contact OpenLDAP (or other solution), and there is no interruption.
Only potential problem is that some pieces of software like to do fancy things with password hashes, so MIAB may not have password hashes stored using the correct algorithm, salt and include fancy formatting. This could be solved by creating a script that either requires users to reset their own passwords, or upon next login, checks the password hash against the current hash and create a new hash that complies with said piece of software we are talking about implementing into MIAB (like OpenLDAP).
Everything uses Dovecot, and Dovecot queries the Sqlite database.
Ok, it’s technically sensible, but I am always pretty strict about making the project more complex. Every new component makes the project harder for everyone to understand and harder to maintain. And while I want Mail-in-a-Box to be useful for enterprise users, this is something that only enterprise users will find useful — for everyone else the project would be worse.
While I agree adding new features would be pointless in some case, adding OpenLDAP would not really affect users if you do a replacement of SQLite with OLDAP.
Of course this can help with easily integrating other applications into MIAB but maybe that falls outside the scope of what needs to be done.
That said - Implementing a different protocol for all backend systems for be a huge hassle. An even better option than what I stated before is an SQLite ↔ OLDAP bridge instead where OpenLDAP is installed on another server, and a bridge application is used to interface the authentication from OLDAP to Dovecot / SQLite.
@Eliter - If you have some Linux experience, I would suggest forking MIAB and trying to implement OpenLDAP.
Maybe the best way is not to add LDAP to MiaB but to allow MiaB to be more configurable for advanced users. This might be able to be accomplished by using configuration files that can be overridden by user configurations.
So instead of code like this in setup/mail-users.sh:
# SQL statement to check if we handle incoming mail for a domain, either for users or aliases.
cat > /etc/postfix/virtual-mailbox-domains.cf << EOF;
dbpath=$db_path
query = SELECT 1 FROM users WHERE email LIKE '%%@%s' UNION SELECT 1 FROM aliases WHERE source LIKE '%%@%s'
EOF
there would be a configuration file in the conf/postfix directory with:
dbpath=$db_path
query = SELECT 1 FROM users WHERE email LIKE '%%@%s' UNION SELECT 1 FROM aliases WHERE source LIKE '%%@%s'
Then the user can create her own version of the file that points to a MySQL database or LDAP server. Obviously the configuration files would have to be run through a template engine that would allow for replacement of variables ($db_path above) with their proper values.
Also, a method to allow custom configuration of postfix would also be needed. But this would be simple as it could be a file of postconf settings to be applied after MiaB’s configuration process, effectively overwriting the standard MiaB settings.
This approach would not only allow for different authentication sources, but would also make MiaB more flexible for those users who wish to extend/modify it.
Let’s take Mediawiki ( MediaWiki ) for example. It is a piece of software that uses PHP, and has its own login/registration system. Let’s say that a user has a MIAB server, and is also running Mediawiki on Apache.
I have already gone knee-deep in how the system works, and still can’t figure it out very well. Once simply does not
Back a year ago, before I know Single-Sign-On was a thing and Keycloak ( https://www.keycloak.org/ ) was a thing, I was managing/providing tech for a small team of people (10-20), we (I) were running a Mediawiki and I was trying to unify users across several services (Apache passwd whatever-it’s-called, and create Linux users). I created a quick PHP script that would take a user’s plaintext password, hashes it, and stored it in a file. Keep in mind, this was a non-profit cause I was doing work with, so the wasted time wasn’t a big deal.
Little did I know after the meeting was over, Mediawiki plaid favorites with how they hashed their passwords. You should look into it. I learned a lot about hashing, and the default BLOWFISH or whatever it’s called does not work with Mediawiki’s crap. That said, I could not just simply take a hashed password and feed it directly into Mediawiki’s database (MySQL/MariaDB, they had their own database).
You’ll soon realize that it’s a fricking nightmare to shove data from one piece of software into another and call it a user. What’s better is to pick ONE piece of software to maintain users, and use the same or a difference piece of software to communicate between the user management software and other applications, and have all other applications check to make sure a user is authenticated.
This is why authentication standards exist like Oauth, LDAP, OpenID, etc…
I just don’t know what the best model is. Keycloak is supposed to streamline the process, but I haven’t been able to get Keycloak to work with OpenLDAP, and figure out how in the hell it all works.
@murgero, I have tried a handful of times, and have tried to get it working for several hours when I did try, but my knowledge on authentication is very limited. If you can help me out, I’d be willing to try it.
@JoshData, @murgero, @jrsupplee, a few things that I am thinking, after trying to put together a fork that HAS OpenLDAP on it (not sure how to implement it quite yet):
Why doesn’t Mailinabox exit with a non-zero status when it has an error? This would be helpful, if anyone integrated the MIAB install with a script. Also, I would think it would be good practice.
I’m gonna have the fork install phpldapadmin. It’s like phpmyadmin, which is a MySQL web interface for a MySQL server. phpldapadmin will it make it MUCH easier to administrate an LDAP server. But we don’t know what we’re doing yet, so it may end up getting removed alltogether.
2A. phpldapadmin comes shipped with an major error (if I recall correctly), and there is a simple fix that I will have to Google. You have to change some of the PHP to get it to actually work.
2B. I have never configured an nginx server before. Hopefully I can figure it out. It’s just like Apache, right? 
Probably wrong.
2C. phpldapadmin tries to install Apache2 by default. However, I have noticed that if the nginx php-cli php-fpm packages are installed, it doesn’t try to install Apache. I’m trying to write safe code that especially makes sure that it doesn’t try to Apache before installing phpldapadmin. Not sure how to do this. I have seen suggestions to use “apt-cache depends [PACKAGE]” and “apt-rdepends -s Suggests [PACKAGE]” (but apt-rdepends isn’t shipped by default). I was having issues getting apt-rdepends -s Suggests to stay quiet and only output stuff IF “apache” is mentioned, but grep wasn’t being nice to me. For now, I won’t check if Apache will be installed.
LDAP’s data will need to be in /home/user-data/ so all data that someone would want to save would be in the same place.
In ./setup/functions.sh on line 47, I would think to define DEBIAN_FRONTEND inside of a subshell, so that the variable does affect any potential code outside of this. In many programming languages, this is the concept of variable scopes or variable localization, I believe. Here is the line of code:
DEBIAN_FRONTEND=noninteractive hide_output apt-get -y -o Dpkg::Options::=“–force-confdef” -o Dpkg::Options::=“–force-confnew” “$@”
I would think to put:
(DEBIAN_FRONTEND=noninteractive hide_output; apt-get -y -o Dpkg::Options::=“–force-confdef” -o Dpkg::Options::=“–force-confnew” “$@”)
@JoshData, sorry for the spam. But I remember a while ago I contributed code to the ubuntu_bionic branch, but I never received credit via git. I’m not upset, but I kinda like having records of my personal accomplishments. You accepted the code into the official repository, and I wanted to know if I contributed in the wrong way or something, because I thought the contributors would show automatically.
EDIT: here is the pull request: https://github.com/mail-in-a-box/mailinabox/pull/1488/commits
It does in some cases, and we can fix it if it doesn’t in other cases.
I would think to put:
Your two bash lines are equivalent (you can try it).
I never received credit via git
Your fix was good! I’m not sure what you’re expecting (that’s not sarcasm — I’m just not sure why you’re asking). Your avatar shows at the top of mailinabox/setup/questions.sh at 641fedddbd53d611e95a0236715f57a056e597d2 · mail-in-a-box/mailinabox · GitHub, for instance.
This topic was automatically closed after 61 days. New replies are no longer allowed.