What are you folks using for self-hosted single sign-on?

I have my little LDAP server (lldap is fan-fucking-tastic – far easier to work with than OpenLDAP, which gave me nothing but heartburn). Some applications can be configured to work with it directly; several don’t have LDAP account support. And, ultimately, it’d be nice to have SSO - having the same password everywhere if great, but having to sign in only once (per day or week, or whatever) would be even nicer.

There are several self-hosted Auth* projects; which is the simplest and easiest? I’d really just like a basic start-it-up, point it at my LDAP server, and go. Fine grained ACLs and RBAC support is nice and all, but simplicity is trump in my case. Configuring these systems is, IME, a complex process, with no small numbers of dials to turn.

A half dozen users, and probably only two groups: admin, and everyone else. I don’t need fancy. OSS, of course. Is there any of these projects that fit that bill? It would seem to be a common use case for self-hosters, who don’t need all the bells and whistles of enterprise-grade solutions.

  • corsicanguppy@lemmy.ca
    link
    fedilink
    English
    arrow-up
    1
    ·
    48 minutes ago

    Kerberos, you say? Single sign-on?

    Have you heard about the LDAP and Kerberos configured as part of setting up samba4ad?

    I accidentally enabled SSO SSH a few years back. My samba units aren’t on PIs but they could be. They’re just on tiny tiny VMs.

  • mongoose@lemm.ee
    link
    fedilink
    English
    arrow-up
    6
    ·
    edit-2
    10 hours ago

    FreeIPA + Keycloak

    FreeIPA includes Kerberos so the SSO extends to Linux logins. Further, Keycloak supports Kerberos so if I’m logged in on an FreeIPA enrolled client Keycloak is transparent with no additional password. Thus, anything I can goes through Keycloak, otherwise manual LDAP to FreeIPA.

    FreeIPA also handles most of my homelab’s DNS and honestly was not too hard to setup. I’m running it in a Alma Linux VM on Proxmox so it will be supported for a while.

  • retro@infosec.pub
    link
    fedilink
    English
    arrow-up
    4
    ·
    9 hours ago

    LLDAP + Authelia

    I actually moved from Authentik to Authelia because it was easier for me to add a couple of lines to a yaml than to navigate Authentik’s web ui. Authentik is more feature-full but I’m only running SSO for myself and a couple of others at home.

    • 𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍OP
      link
      fedilink
      English
      arrow-up
      1
      ·
      3 hours ago

      Yeah, that sounds ideal. I’d prefer editing a file than administering through a web page.

      I’m checking Authelia right now.

      SSO is part, but not all, of the picture. There’s also multi-system passwords, for things like sudo, and non-web service authentication; most of the stuff like OAUTH is really hacky to make work outside of web environments.

      I’ve considered Vault for some of the inter-service authentication, but there’s not broad support built into services and it’s yet another thing to mess with.

      LDAP forms a good base for most use cases, and so keeping it as the source of truth is important for me. And then, as few other layers on top to get SSO. Authelia is looking like the best solution.

  • Nibodhika@lemmy.world
    link
    fedilink
    English
    arrow-up
    5
    ·
    14 hours ago

    I tried Authelia but couldn’t set it up, so I’ve been using Authentik and have been quite happy. The only downside is that I had to configure it using the GUI instead of with config files, which I think would have been a point for Authelia, but couldn’t get it to work properly.

  • node815@lemmy.world
    link
    fedilink
    English
    arrow-up
    8
    ·
    18 hours ago

    Pocket id is my go to. I used to use Authentik, but it was overkill for us. Pocket ID is pretty simple to use and has a very nice interface to add your users and clients. Uncluttered and straight and to the point. Pocket ID doesn’t use UN/PW Combos. Instead, you use Passkeys as in webAuthn devices to log in, which IMHO is one of the better security paths.

    https://github.com/pocket-id/pocket-id

    • 𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍OP
      link
      fedilink
      English
      arrow-up
      1
      ·
      3 hours ago

      If Pocket ID and Passkeys are like most modern “solutions”, they ignore everything that isn’t web, or human. Have you hooked any services together using it? Like having Home Assistant authenticate against mpd?

      • Wigglytuff@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 hour ago

        Passkeys work on whatever platforms your passkey is compatible with. I store mine in my BitWarden vault which works on web/PC/mobile just fine.

        Pocket ID is an OpenID Connect provider (basically OAuth), so it depends on whichever apps you’re using having support for that.

        Home Assistant does not natively support OIDC, but there is a community project in active development which aims to add support.

  • SK@hub.utsukta.org
    link
    fedilink
    arrow-up
    30
    arrow-down
    1
    ·
    1 day ago

    Authentik! i’ve been using it since over a year and its been a wonderful experience. supports many protocols and is updated regularly, as a beginner i didnt have difficulty setting it up, has decent documentation for integrations.

      • johntash@eviltoast.org
        link
        fedilink
        English
        arrow-up
        2
        ·
        19 hours ago

        I’d also recommend Authentik. It’s simpler than something like keycloak imo and works pretty well. They also have guides for quite a few self hosted services.

        I did have issues with it being slow at some point, but an update fixed it iirc.

    • Flipper@feddit.org
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 day ago

      I don’t like the interface for setting up flows. Feels needlessly complicated.

  • roofuskit@lemmy.world
    link
    fedilink
    English
    arrow-up
    23
    arrow-down
    1
    ·
    1 day ago

    Just copied and pasted my comment from another recent post about Authelia.

    After recently trying Authelia I gave up and moved to Authentik. Very much appreciate the all in one functionality of it. The company even paid a YouTuber to make a bunch of useful step by step tutorials and they have been invaluable. They also have a number of SSO integration instructions for various software. I highly recommend giving it a try if you’re in the market for an easy enough self hosted SSO and proxy password system.

  • keyez@lemmy.world
    link
    fedilink
    English
    arrow-up
    9
    ·
    23 hours ago

    I used to run key cloak backed by LDAP. Few months ago moved to Authelia and after many hours of tinkering and setting up sites I haven’t had to touch it except to add a new URL or user.

    I slightly disagree with the other commenter I didn’t find it easy or straightforward but once I finally found what worked for my setup its been great.

    Imagine Authelia is the caddy of SSO. Powerful, intimidating but very efficient. Also all configs are in like 3 files and things aren’t going to change without FS access which only I the admin have.

    • Scrubbles@poptalk.scrubbles.tech
      link
      fedilink
      English
      arrow-up
      2
      ·
      21 hours ago

      I’ve tried and failed a couple of times, would you mind sharing (or dming) your example config? Maybe I’m just a been with sso and can’t figure it out

      • keyez@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        4 hours ago

        Heres what I’m running:

        authentication_backend:
          file:
            path: '/config/users_database.yml'
            watch: false
            search:
              email: false
              case_insensitive: false
            password:
              algorithm: 'sha2crypt'
        
        access_control:
          ## Default policy can either be 'bypass', 'one_factor', 'two_factor' or 'deny'. It is the policy applied to any
          ## resource if there is no policy to be applied to the user.
          default_policy: 'deny'
        
          networks:
            - name: 'internal'
              networks:
                # - '10.10.0.0/16'
                - '192.168.1.0/24'
            - name: 'VPN'
              networks: '10.0.1.0/24'
        
          rules:
            ## Rules applied to everyone
            - domain: '*.mydomain.com'
              policy: 'one_factor'
        
        session:
          ## The secret to encrypt the session data. This is only used with Redis / Redis Sentinel.
          ## Secret can also be set using a secret: https://www.authelia.com/c/secrets
          secret: 'insecure_session_secret'
        
          ## Cookies configures the list of allowed cookie domains for sessions to be created on.
          ## Undefined values will default to the values below.
          cookies:
          #   -
              ## The name of the session cookie.
            - name: 'authelia_session'
        
              ## The domain to protect.
              ## Note: the Authelia portal must also be in that domain.
              domain: 'mydomain.com'
        
              ## Required. The fully qualified URI of the portal to redirect users to on proxies that support redirections.
              ## Rules:
              ##   - MUST use the secure scheme 'https://'
              ##   - The above 'domain' option MUST either:
              ##      - Match the host portion of this URI.
              ##      - Match the suffix of the host portion when prefixed with '.'.
              authelia_url: 'https://auth.mydomain.com/'
        storage:
          postgres:
            ....
        
        identity_providers:
          oidc:
            ## Cross-Origin Resource Sharing (CORS) settings.
            cors:
              ## List of endpoints in addition to the metadata endpoints to permit cross-origin requests on.
              endpoints:
                 - 'authorization'
                 - 'token'
                 - 'revocation'
                 - 'introspection'
                #  - 'pushed-authorization-request'
                #  - 'userinfo'
        
              ## List of allowed origins.
              ## Any origin with https is permitted unless this option is configured or the
              ## allowed_origins_from_client_redirect_uris option is enabled.
              allowed_origins:
                - 'https://mydomain.com/'
                - 'https://grafana.mydomain.com/'
                - 'https://wiki.mydomain.com/'
                - 'https://foodz.mydomain.com/'
        
              ## Automatically adds the origin portion of all redirect URI's on all clients to the list of allowed_origins,
              ## provided they have the scheme http or https and do not have the hostname of localhost.
              allowed_origins_from_client_redirect_uris: true
            ## Clients is a list of known clients and their configuration.
            clients:
              - client_id: 'grafana'
                client_name: 'Grafana'
                client_secret: 'XXXXXX'
                public: false
                consent_mode: 'pre-configured'
                authorization_policy: 'one_factor'
                require_pkce: true
                pkce_challenge_method: 'S256'
                redirect_uris:
                  - 'https://grafana.mydomain.com/login/generic_oauth'
                scopes:
                  - 'openid'
                  - 'profile'
                  - 'groups'
                  - 'email'
                userinfo_signed_response_alg: 'none'
                token_endpoint_auth_method: 'client_secret_basic'
              - client_id: 'wiki'
                client_name: 'Wiki'
                client_secret: 'XXXX'
                consent_mode: 'pre-configured'
                public: false
                authorization_policy: 'one_factor'
                require_pkce: true
                pkce_challenge_method: 'S256'
                redirect_uris:
                  - 'https://wiki.mydomain.com/oidc/callback'
                scopes:
                  - 'openid'
                  - 'profile'
                  - 'groups'
                  - 'email'
                userinfo_signed_response_alg: 'none'
                token_endpoint_auth_method: 'client_secret_basic'
              ....
        
        

        Then my users_database.yml looks like:

        users:
          authelia:
            disabled: false
            displayname: "Test User"
            password: ""
            email: authelia@authelia.com
            groups:
              - admins
              - dev
          user001:
            disabled: false
            displayname: 'User 001'
            password: "$6$rounds=50000$XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
            email: test@gmail.com
            groups:
              - admins
              - users
        
  • irotsoma@lemmy.blahaj.zone
    link
    fedilink
    English
    arrow-up
    4
    ·
    22 hours ago

    Keycloak. Took me a bit to learn the basics, but it has been way easier to troubleshoot than Authentik and has more features. If you need something that mimics LDAP rather than syncing with an existing LDAP, then Authentik is pretty good. I don’t use LDAP, though.

      • irotsoma@lemmy.blahaj.zone
        link
        fedilink
        English
        arrow-up
        2
        ·
        6 hours ago

        If you want to keep your LDAP as the source of truth, then Keycloak is also a very good option. I did that originally, but decided I only had a couple of things needing LDAP and that wasn’t worth keeping it around. Authentik was a good way to emulate an LDAP but with a different back end. But Keycloak is definitely my recommendation in your case.

  • steventhedev@lemmy.world
    link
    fedilink
    English
    arrow-up
    7
    ·
    edit-2
    1 day ago

    Keycloak might seem a little daunting to start with, but is basically glue between your idp (ldap) and whatever apps need to authenticate.

    • Grunt4019@lemm.ee
      link
      fedilink
      English
      arrow-up
      4
      ·
      23 hours ago

      My issue with keycloak is that the documentation is very poor as a beginner. It and almost any other guides online assume you already know things that you may not so I wasn’t able to get past that hurdle.

      • steventhedev@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        16 hours ago

        Strongly agree. A guide for dead simple setups would be incredibly useful (e.g. gsuite as idp, oauth for a single app).

        It took me a few days to get that basic setup working, and a few days more to improve it. But once it was up, it was rock solid.

    • jaark@infosec.pub
      link
      fedilink
      English
      arrow-up
      4
      ·
      1 day ago

      Another for Keycloak. Though it is probably overkill for many people’s needs in here - it certainly is for mine! But it is what I have up and running and see no need to change to a simpler option.

    • Matt The Horwood@lemmy.horwood.cloud
      link
      fedilink
      English
      arrow-up
      1
      ·
      24 hours ago

      Keycloak here, I plugged my keycloak into my Google workspace. Yes I know Google!!

      But the login flow is amazing and I get all the MFA without the faff

  • hendrik@palaver.p3x.de
    link
    fedilink
    English
    arrow-up
    4
    ·
    edit-2
    1 day ago

    I use KaniDM and configured everything with OAuth2. That was the easiest and most straightforward I could find. But I don’t think they bothered implementing LDAP. Other platforms I tried are Authentik, Authelia, Keycloak, Zitadel… They’re all a bit heavier and have other/more features, but there wasn’t one I really fell in love with.

    • 2xsaiko@discuss.tchncs.de
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      1 day ago

      Kanidm has LDAP support but it’s read-only. You should prefer OAuth though since LDAP is locked to password login.