I have a lot of different services which I self host for me and my family like:

  • PeerTube
  • Lemmy
  • Mastodon
  • Synology NAS
  • TTRSS
  • NextCloud
  • Matrix
  • HomeAssistant
  • etc.

Right now every family member needs to create a user on each of those services and have a different password on them, which is OK when you use a Password Manager, but most of my extended family members don’t. And they often forget their password and stop using the service because they can’t figure out how to reset the password with each and every service.

I would like to try to consolidate all of it with a Single Sign-On (SSO) solution but It’s not obvious to me if there is one which is not overly over engineered for hundreds of thousands of users but small and lightweight, perhaps even easy to set up.

I tried OpenLDAP but Jesus that was very involved.

  • vegetaaaaaaa@lemmy.world
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    1 year ago

    I tried OpenLDAP but Jesus that was very involved.

    OpenLDAP is easy :) Once you understand LDAP concepts.

    Check this and read through the tasks/ directory (particularly openldap.yml and populate.yml. It sets up everything needed for an LDAP authentication service (if you don’t use ansible you can still read what the tasks do and you should get a pretty good understanding of what’s needed, if not let me know).

    In short you need:

    • slapd (the OpenLDAP server)
    • set up a base LDAP directory structure (OUs/Organizational Units, I only use 3 OUs: system, users and groups)
    • an admin user in the LDAP directory (mine is admin directly at the base of the LDAP directory)
    • (optional but recommended) a so-called bind user in the LDAP directory (unvprivileged account that can only list/read users/groups) (mine is bind under the system OU)
    • (optional) groups to map users to their roles (e.g. only users in access_jellyfin are allowed to login to jellyfin)
    • actual user accounts, member of one or more groups if needed

    When you login to an application/service configured to use the LDAP authentication backend, it connects to the LDAP directory using the bind user credentials, and checks that the user exists (depending on how you configured the application either by name, uid, email…) , that the password you provided matches the hash stored in the LDAP directory, optionally that the user is part of the required groups. Then it allows or denies access.

    There’s not much else to it:

    • you can also do without the bind account but I wouldn’t recommend it (either configure your applications to use the admin user in which case they have admin access to the LDAP directory… not good. Or allow anonymous read-only access to the LDAP directory - also not ideal).
    • slapd stores its configuration (admin user/password, log level…) inside the LDAP directory itself as attributes of a special entity (cn=config), so to access or modify it you have to use LDIF files and the ldapadd/ldapmodify commands, or use a convenient wrapper like the ansible modules tools used above.
    • once this is set up, you can forget LDIF files and use a web interface to manage contents of the LDAP directory.
    • OUs and groups are different and do not serve the same purpose, OUs are just hierarchical levels (like folders) inside your LDAP tree. groups can contain multiple users/users can have multiple groups so they’re like “labels” without a notion of hierarchy. You can do without OUs and stash everything at the top level of the directory, but it’s messy.
    • users (or other entities) have several attributes (common name, firstname, lastname, email, uid, password, description… it can contain anything really, it’s just a directory service)
    • LDAP is hierarchical by nature, so user with Common Name (CN) jane.doe in OU users in the directory for domain example.org has the Distinguished Name (DC) cn=jane.doe,ou=users,dc=example,dc=org. Think of it like /path/to/file.
    • to look for a particular object you use filters which are just a search syntax to match specific entities (object classes) (users are inetOrgPersons, groups are posixGroups…) and attributes (uid, cn, email, phonenumber…). Usually applications that support LDAP come with predefined filters to look for users in specific groups, etc.
  • nickwitha_k (he/him)@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 year ago

    I’d suggest something like Keycloak or earning the wizard robe and beard by buckling down and learning OpenLDAP. The biggest suggestion that I have though is to have a disaster recovery plan for even your auth system goes down. Don’t be like Facebook and lock yourself out without any hope of regaining entry (or, if you’re a fan of Russian Roulette, do).

      • nickwitha_k (he/him)@lemmy.sdf.org
        link
        fedilink
        English
        arrow-up
        0
        ·
        11 months ago

        I’m still trying to cover up with a good one to allow more self-hosting. Probably a SHTF security key kept in a safe that can be used with physical access.

        My “plan” is to SSH in and figure out what’s wrong.

        The problem here being that you have a circular dependency:

        1. SSH auth requires OpenLDAP/Keycloak
        2. SSH access is required to fix broken OpenLDAP/Keycloak
        3. GOTO 1
        • Deebster@lemmyrs.org
          link
          fedilink
          English
          arrow-up
          1
          ·
          11 months ago

          My SSH auth uses SSH keys stored in authorized_keys, but I see your point. For me, OpenLDAP will be letting users in to the various services and SSH is outside that. I suppose SFTP could be something I want, but I’d be tempted to put a new sshd inside a container and have it more restricted than the system one.

          I think the backup key idea is definitely the most broadly applicable, but there’s physical/KVM for a more old school access route.

          • nickwitha_k (he/him)@lemmy.sdf.org
            link
            fedilink
            English
            arrow-up
            2
            ·
            11 months ago

            That makes sense. I like the idea of combining physical key with physical/KVM access so that there is no password auth (at least, not without a second factor).