Moderne Benutzerverwaltung für ein paar Dienste

h^2

h^2

hat ne Keule +1
Bis jetzt habe ich so ziemlich alles direkt über Nextcloud gemacht (Dateien, CarDAV, CalDAV, Subsonic...). Da konnte man auch bequem die Nutzer verwalten. Aber die Nextcloud ist mir zu klobig geworden, und einige Sachen haben nie sauber funktioniert, und ich will auch ein paar neue Features, die Nextcloud nicht kann. Deswegen sollen jetzt separate Dienste her. Um die zusammen zu binden, brauche ich Benutzerverwaltung! Ich habe da an LDAP gedacht, aber an anderen Stellen gelesen, dass OpenID-Provider jetzt der heiße Scheiß seien (da kann man die IDs dann auch woanders verwenden?).

Was würdet ihr mir empfehlen?

Das sind meine Requirements:
  • Nur ein Admin (ich)
  • ca 5 regelmäßige Nutzer, ca 10-15, die es selten nutzen
  • Ich will ein (Web-)UI über das ich Nutzer anlegen kann, Password-Policies enforcen, den letzten Login sehen etc; Gruppen sind nicht absolut nötig aber nice-to-have
  • Nutzer sollten selber in der Lage sein ein Password-Reset zu requesten.
  • Möglichst breiter Support bei anderen Diensten.

Alles auf FreeBSD. Sollte als Paket verfügbar sein, oder sich zuverlässig selber aktualisieren.

Danke!

edit: Ich brauche keine 2FA, Tokens, oder ähnliches. Allerdings wäre ein Auto-lock nice, wenn ein User sich x Zeit nicht angemeldet hat.
edit2: Also, es geht mir sowohl um die Frage: LDAP oder was anderes? Als auch um die Frage: Wenn LDAP, dann welcher Server (und welches UI falls separat)?
 
Zuletzt bearbeitet:
Das sagen unseren zukünftigen Overlords:
1766612679063.webp
 
Ist irgendwas davon DAA (dümmster anzunehmender Admin) kompatibel?
Praktikabeles Webfrontend und so?

Ich hätte in dem Setup 120 Nutzer für vier Linuxkisten zu verwalten.
 
Ich baue beruflich ja unter anderem Authentifizierungs- und Authorisierungsinfrastrukturen auf Basis von SAML und OpenID Connect (OIDC) und ehrlich gesagt würde ich mir das privat nicht antun wollen. Beides sieht auf den ersten Blick ganz fluffig und elegant aus, das neuere OIDC mehr als die alte Microsoft-Ausgeburt SAML. Aber beiden liegt auch eine enorme Komplexität mit einer Vielzahl Fallstricke zugrunde. Schon um es sinnvoll implementieren und betreiben zu können, muss man die jeweiligen Protokolle, die zugehörige Nomenklautur und implizite Implikationen zumindest auf hoher Ebene verstanden haben. Sobald es Probleme gibt und Dinge nicht oder nicht mehr funktionieren, auch in den Tiefen bis runter zu Konzepten wie JSON Web Tokens. Da rächt sich dann auch schnell, dass sich OIDC seine Eleganz durch eine größere Komplexität als SAML erkauft... Föderieren wird man privat hoffentlich nicht wollen, aber spätestens da wird es dann richtig eklig.

Wenn man es trotzdem versuchen will, würde ich OIDC nehmen. Es ist moderner als SAML und viele neue Software bietet gute OIDC-Integration, aber nur überschaubare SAML-Integration. OIDC-IDMs gibt es mehrere. Das im akademischen Bereich sehr verbreitete Shibboleth würde ich in der "normalen" Welt vermeiden, es ist zwar extrem dynamisch und anpassbar, aber auch abartig komplex und es zu betreiben ist schon fast ein Vollzeitjob. SimpleSAMLphp ist überschaubar und gut dokumentiert, aber wie der Name schon sagt in erster Linie ein SAML-IDP. Solange man nicht doch SAML benötigt, würde ich es nicht empfehlen. Bleiben die Schwergewichte:

Das ist einmal Keycloak, eine Java-Anwendung und als FreeBSD-Port verfügbar. Wobei ich mir, da man Keycloak immer kontrolliert updaten sollte, überlegen würde, es nicht manuell an den Ports vorbei zu installieren. Als Java-Anwendung ist das schnell getan, die offizielle Distribution liefert ein praktisches Wrapperscript für den Start und Administration mit. Keycloak ist zwar prinzipbedingt keine einfache Anwendung, aber dennoch recht zugänglich und auch wenn die offizielle Doku nur so lala ist, gibt es, allein durch die Tatsäche, dass es das wohl neben Microsoft ADFS bzw. der Cloudvariante EntraID vertreiteste IDM ist, praktisch unendlich viele Ressourcen dazu. Keycloak ist in kleineren Setups schnell aufgesetzt, das es alle benötigten Komponenten mitbringt, es ist von Haus aus multitenantfähig und es hat ein recht gutes Webfrontend.

Die meist genutzte Alternative ist Authentik. Es scheint keinen FreeBSD-Port zu geben, was es praktisch schon ausschließt. Das verwundert auch nicht, ist es doch in erster Linie als Container-Anwendung konzipiert. Authentik ist "DAU-freundlicher" als Keycloak, weil es die Komplexität von OIDC besser verdeckt. Das wird allerdings problematisch, wenn Dinge nicht funktionieren. Der Vollständigkeit halber muss ich auch noch Zitadel nennen, auch davon scheint es keinen FreeBSD-Port zu geben und ich habe auch keine eigenen Erfahrungen damit.
 
jmt schrieb:
Vielleich reicht das hier: lldap
Zum Vergrößern anklicken....

Oh, das sieht interessant aus, und das hatte ich noch nicht auf dem Schirm, danke!

Yamagi schrieb:
Ich baue beruflich ja unter anderem Authentifizierungs- und Authorisierungsinfrastrukturen auf Basis von SAML und OpenID Connect (OIDC) und ehrlich gesagt würde ich mir das privat nicht antun wollen.
Zum Vergrößern anklicken....

Danke für die fundierte Einschätzung. Ja, neige eher zu LDAP gerade.

medV2 schrieb:
Was willst du dagegen authentifizieren?
Zum Vergrößern anklicken....

  • Dateien: noch unklar, vielleicht Seafile; hatte auch mal an OpenCloud gedacht, aber die brauchen SAML
  • CalDAV, CardDAV: noch unklar
  • Passwörter: Vaultwarden
  • Videos: Jellyfin
  • Audio: wahrscheinlich navidrome

Insgesamt versuche ich von den PHP-basierten Webstacks weg, hinzu mehr nativen Anwendungen (aber auch nicht dogmatisch). Muss auch nochmal gucken ob da alles eigene Jails bekommt, oder separate. Manchmal ist das jeweilige Web-Interface ja auch separat.
 
Ich selbst kenne aus meinem beruflichen Umfeld lediglich Keycloak. Dort dient es zur Abstrahierung der dahinter liegenden LDAP und Kerberos Infrastruktur. Der Login über den Browser via spnego funktioniert problemlos. Im Homelab verwende ich keycloak lediglich zur Authentifizierung eines Users an gitea sowie argocd.

Die Login Prozedur kann man auch via Skript durchführen, den erhaltenen jwt Token kann man dann, wie in unserem Fall via Bearer Token im Header an den an keycloak angebundenen Service (ein k8s cluster) übergeben. Die authorization übernimmt dann der angebundene Service im Falle von k8s via RBAC selbst.

Es lohnt sich auf jeden Fall die Admin Events in der Realm config anzuschalten. Dieser protokolliert im json Format die hinzu gefügten Parameter, die man dann bequem in die via Ansible generierte config des clients übernehmen kann.

Generell ist die Ansible Unterstützung sehr gut und ermöglicht einen shared nothing Ansatz im Falle eines kompletten Ausfalls. Wenn LDAP als Backend konfiguriert wird, muss man sich nicht einmal um die User und Gruppen Konfiguration kümmern, da diese auf Wunsch RO bzw. RW importiert werden können. Wie sich die LDAP Verwaltung aus Keycloak heraus gestaltet kann ich allerdings nicht sagen.

Ich selbst kratze damit lediglich an der Oberfläche der Möglichkeiten, wie beispielsweise die bereits von @Yamagi erwähnte User Federation.

Die Lernkurve insgesamt war für mich allerdings gefühlt steil.
 
Föderation im eigentlichen Sinne kann Keycloak tatsächlich de facto gar nicht. Nur "falsche" Föderation durch ein zentrales Nutzerverzeichnis wie LDAP. SAML Federation unterstützt es schlicht nicht, was schade ist, da praktisch alle real existierenden Föderationen auf SAML basieren. Man braucht zwingend Föderation-Proxies, mit denen die Komplexität des Gesamtsetups drastisch ansteigt. OpenID Federation ist inzwischen bei Draft 46 angekommen und wird nächstes Jahr vielleicht endlich ein Release sehen. Es gibt experimentelle Implementierungen in Form von Plugins, aber wenn man es will, ist es sinnvoller gleich zum offiziellen Implementierungsprojekt unter https://github.com/keycloak/keycloak/issues/40509 zu greifen. Allerdings wird OpenID kein Spaß werden, man muss nur durch den aktuellen Draft scrollen um das zu sehen: https://openid.net/specs/openid-federation-1_0.html

Aber das nur am Rand. Es gibt meines Erachtens nach keinen sinnvollen Grund um im privaten Umfeld auch nur entfernt über Föderation nachzudenken. Auch im professionellen Umfeld lassen sich meist bessere bzw. handhabbarere Lösungen finden.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben