Maybe a simple solution for external authentication in YunoHost?

Contribute Room Core dev
1

Hi,

I am a professional fire officer, and I am currently managing a Debian server in my fire brigade (Genova, Italy), hosting a couple of applications docker images.

I would like to simplify the management of this server, to allow other colleagues to help me out. I have been studying YunoHost for some time. It seems indeed a great solution: an easy UI for daily maintenance, and the flexibility of a real Linux distro.

But as we have ~600 users (firefighters…), I would like to keep using the same simple custom authentication mechanism we currently have: thanks to a python script, username and password are checked by quering our SMTP server. This is a kind of poor-man SSO.

Reading the docs and the discussions, I learned that YunoHost has a local LDAP server, and currently cannot offer external authentication.

So I would like to try to adapt YH authentication code as follows:

  • The user enters username and password in the YunoHost login panel.
  • YH calls an external custom script to check if the provided username and password are ok (In my case, this would be a simple query of our SMTP server).
    • if username and password are ok: YH calls the local LDAP and check if the user exists:
      • if the user exists in LDAP: YH updates the user password in the LDAP, and allows the authentication.
      • if the user does not exist in LDAP: YH adds the new user to the LDAP (username, email, and password, the rest is set to default), and allows the authentication.
    • if username and password are not ok: YH calls the local LDAP and checks if the user exists:
      • if the user exists in LDAP: YH disables the user in LDAP (eg. by scrambling the password), and rejects the authentication.
      • if the user does not exist in LDAP: YH does nothing, and rejects the authentication.
    • if the external script fails (eg. due to a network error): YH calls the LDAP and checks the provided username and password against the locally cached username and password.
      • If the user exists and the password is ok: YH allows the authentication (resilient when my SMTP is down!).
      • else: YH rejects the authentication.

This would be a very simple method for the YH team to offer the feature of external authentication with a foreign SSO (eg. Google, Active Directory, …) to advanced YH admins.

IMHO this would be a great added value for YH, with a very little maintenance burden for the YH team, because the external script is a responsibility of the admin.

Even if I am not a professional developer, I can try to start this little development and contribute a PR for your evaluation.

So, three questions before starting:

  1. Do you think this idea is reasonable/feasible? or am I missing anything evident in this cold winter evening?

  2. If the previous answer is postive, I kindly ask you to quickstart me: where should I look in YH codebase for user authentication?

  3. And, is anybody else interested in this feature and willing to discuss it a little more?

Thank you very much in advance,
Emanuele Gissi

(PS J’aime bien parler et ecrire en Français aussi)

1 Like
2

Hi Emanuele,

Welcome to the forums!

I have no explicit opinion on offering external user management for Yunohost, either via a custom script or via OAuht or similar. I do think that for external authorization to be included in Yunohost, OAuth is a more durable option, as the standard is widely available with many authorization providers.

Which mailserver do you run? Is it under your control as well, or is it an external service?

For a new user the /home/ directory for that user is populated on account creation, and probably some more things. The first logon would take some extra time.

Depending on the options you have with this mailserver, you could have users added to Yunohost from there: an ssh usercreatoruser@youryuno -C 'yunohost user create ...' could be added to the user creation on the side of the mailserver.

Working from the mailserver would also allow to integrate user creation via the API. In case you had not found it, the documentation is available at Administration from the API or an external application | Yunohost Documentation

I think in the long run (and maybe in the short run as well) it is easier to have the mailserver verify with the LDAP server whether an email belongs to the organization, than the other way around.

Even easier could be to import users and mailboxes from your current mailserver, and use Yunohost’s internal mailserver (Postfix); you probably already thought about that?

3

I’m a bit confused, I think the issue about “using an external authentication” is, in itself not the hardest part technically speaking (though it doesn’t get magically implemented either but the big refactoring of the SSO/portal coming in Bookworm will help having a clearer view about this)

The big question is : YunoHost users must exists locally - otherwise this at least breaks LDAP integration in apps and kind of defeats one of the purpose of YunoHost - so how do you keep the existence of these users in sync with the “external system” ?

One way to achieve this is to use the not-so-well-known user import/export feature available in the webadmin (in the User section, dropdown of the green button ‘Add user’ button). Of course this is also available in CLI. Note that there are options such that the import creates / deletes users which are new / non-existent-anymore in the provided CSV.

I don’t remember wether or not it’s able to import (hashed) passwords or not but I can’t see why this couldn’t be implemented, assuming the hash is in a standard format that LDAP can handle.

So the closest thing I see to “syncing” would be to have a cron job that either exports the DB from YunoHost and get it imported in the external system, or import a dump from the external system to YunoHost. But i don’t know how realistic it is in terms of performance. Also YunoHost is not really designed to handle more than say 200~500ish users, this is very much an unexplored territory and would be surprised that things starts to crumble one way or another

4

@wbk The mailserver is a national service, and we have no control of it, nor can we replace it. We can just query it, as if sending emails.

5

@Aleks My idea was to sync the external users with the local LDAP when the user logs in. The LDAP becomes a local cache of all the users, that were succesfully authenticated.

I really appreciate the assistance you provided.

For now I am probably sticking to my current (suboptimal) solution. But I will keep an eye on YH and the big refactoring of the SSO/portal coming in Bookworm, you mentioned.

Thank you again!