I use Keycloak and OpenLDAP, but if I was setting it up again I’d probably just use Authentik

Keycloak is decent. It has its own built in user database, or it can connect to an “upstream” idp like AD, GitHub, google, fb, basically anything that speaks openid or SAML. Then, it can act as an idp to each service you run. It is a bit of a chore to configure, but compared to other SSO servers it’s pretty good (looking at you shibboleth)

I use keycloak. Pretty steep learning curve, but once properly set up, it can do pretty much anything.

But if you’re in a pinch, NextCloud can act as an OIDC auth provider out of the box.

At the moment I only use lldap. I’ll probably add Authelia at some point …

I started trying out FusionAuth and it’s been pretty neat. I off-load my auth to Google because I don’t want yet another username/password nor do I want to be responsible in storing it, but you can certainly use built-in auth if your objective is to stop using external auth. I currently have my Kasm Workspace deployed behind it, so when user lands on Kasm, they get bounced to FusionAuth where there’s a login prompt and Login w/ Google button; when they authenticate (be it through built-in auth or Google in my case), they get bounced back to Kasm Workspace in their account. This was deployed using docker compose, so I just annotate containers I want to protect w/ some labels, traefik handles all the glue work. I really like the way it worked out.

I’d imagine something like Authelia, which gets pushed a lot as well, would be able to offer a similar if not identical workflow.

For Lemmy, at this time, I don’t think it is possible to gate it like that, otherwise inbound federation (i.e.: comment replies to this post) won’t make it into your instance.

deleted by creator

I’ve found Zitadel to be the best open source Oauth2 provider. It also supports terraform for a fully IaC approach to declaring your users and their permissions.

I use Pomerium! https://www.pomerium.com/docs

I use authelia. It’s pretty straight forward to get started with, I just use the yaml user file and a SQLite database for sessions. I’m running it in podman with auto updates enabled for the tag I’m using (can’t remember which tag, but not latest).

I then use their tutorials as a base for the systems I want to use oidc with (grafana, miniflux…), or just redirect traffic through my reverse proxy to services that lacks proper authentication (looking at you, *arr stack).

I use caddy and traefik for reverse proxy, and it’s very simple to use forward_auth and similar with it.

It took an evening to figure it out but it’s well worth it!

I’m using Authentik with openID or saml for all my sso. I don’t want to ever touch LDAP.

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.

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

I used plain Kerberos. I stopped, because sometimes I don’t want to be logged in automatically. Privacy and multi-account systems get more difficult.

What I would dearly like is an SSO system that can also act as a drop-in replacement for Kerberos. Existing krb5 servers (on Linux) are ancient, quirky, and underdocumented, but kerberos is so useful at a CLI level. I’ve always maintained separate LDAP & Kerberos instances, and the thing stopping me from moving to something more modern is that I’m holding out for that kerberos feature…

Might not be quite what you want, but if you just need to block all access to everything unless logged in, then integrating a hosted SSO into your ingress is a simple, low management option.

I’ve been using an old trafeik setup with Google’s SSO, whitelisting certain accounts, and had no problems with it for years.