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.
 
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. 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.
Zum Vergrößern anklicken....
Also, ich habe es mal mit Authelia probiert, weil das in den Ports ist und oft als das einfachste von den Dingern beworben wird. Aber auch das schien mir extrem frickelig und es hat sehr unzuverlässig funktioniert. Nachdem ich irgendwann angefangen habe die Cookies von Browser-Sessions zu debuggen, habe ich mich entschieden das wieder rauszureißen und bei reinem LLDAP zu bleiben.

Dazu kommt etwas, das ich nicht bedacht habe: wenn man einen Dienst so einstellt, dass er über OIDC authentifiziert und nicht über LDAP, dann muss man auch diesen Mechanismus wählen. Das bedeutet für etwas wie Jellyfin dann aber auch, dass normale Clients (sprich das Ding auf dem Fernseher) damit nicht gar nicht mehr authentifizieren können. Gleiches gilt für *DAV clients... Das ist damit ziemlich genau das Gegenteil von dem was ich will, denn die nativen Schnittstellen der Dienste sollen wirklich weiterhin funktionieren.
 
In den Ports gibt es das wunderbar sehr schlanke https://www.freshports.org/www/pocket-id/ was auch ein lldap Backend nutzen kann/könnte, aber nicht muss. Damit habe ich so ziemlich alle internen Systeme per OIDC angebunden (forgejo, home assistant, immich, linkding, miniflux, paperless, etc). Die Authentifizierung erfolgt dann bequem über Passkeys, was ich gerade im privaten/internen Umfeld als echte Erleichterung empfinde, da sich die Keys auch in Keepass oder Vaultwaren speichern lassen.

Leider sind so Dienste wie *DAV, die vom Protokoll jer ja eine direkte Authentifizierung haben, dann immer noch auf Benutzername/Kennwort angewiesen.
Diese Dienste könnten sich aber per lldap authentifizieren, damit wäre diese Lücke auch geschlossen, ist bei mir aber auch noch eine Baustelle.
 
Ich habe diesen Thread hier zum Anlass genommen, ein kleinens Tool zu schreiben. Ein Frontend für OpenBSDs ldapd. Es sollte aber auch mit anderen LDAP-Servern laufen. Es deckt genau meine Use-Case ab (wen wunderts... :)) und ermöglicht es, Benutzer und Gruppen per Web zu administrieren.Der Unterschied zu lldap ist, dass es als Backend einen LDAP-Server nutzt und keinen eigenen implementiert.
Weft
 
Naja, ich würde ja sagen die sachen die du hier vergleichst sind eigentlich für die Lösung unterschiedlicher Probleme gedacht.

Ein LDAP Server ist ein Verzeichnisdienst, also eigentlich eine auf lookup optimierte Art von Datenbank. Da kannst du auch Nutzer und Passwörter drüber abbilden was vermutlich auch der häufigste Anwendungsfall ist.

Ein OpenID Connect Provider ist erstmal nur ein reiner Authentifizierungsdienst, bei dem es in der Regel auch üblich ist dass du noch eine Datenbank brauchst um deine Nutzerinformationen zu speichern, z.B. in Form eines LDAP Verzeichnisses.

Dadurch ergeben sich eben auch ganz unterschiedliche Eigenschaften. Nutze ich LDAP Authentifizierung binde ich eine Anwendung an den LDAP an, sie muss also selbst im Verzeichnis nach den Nutzern suchen und nimmt selbst die Authentifizierung gegen das Directory vor. Das bedeutet auch, dass du deiner Anwendung vertrauen musst. Sie hat schließlich Zugriff auf die im LDAP abgelegten Daten.

Bei OIDC dagegen hast du den seperaten OIDC Provider, deine Anwendung kriegt einen Request rein, sieht dass an dem kein Token hängt und macht einen Redirect auf den OIDC Provider. Dieser macht die Authentifizierung und macht einen Redirect zurück auf die Anwendung. Dadurch wird der OIDC Provider ein Single Point of Contact für die Authentifizierung. Das kann aus Security Sicht durchaus Sinn machen.

Für eine einfache Umsetzung würde ich ja einen Dex mit LDAP Backend empfehlen, das ist schnell konfiguriert und ein schlankes Setup. Komplexe Usecases wirst du damit nicht umgesetzt kriegen aber für "Zuhause" reichts und man muss sich nicht die Komplexität von Keycloak ans Bein binden.
 
Kann mich meinem Vorredner nur anschließen.

Neben dex hatte ich schon von Authelia als einfach zu konfiguriere Alternative gehört.

Eine einfache Keycloak Installation im Homelab sehe ich als geringes Problem.

Sobald man allerdings beginnt Reverseproxies vor den keycloak zu stellen fangen die Themen an komplex zu werden.

Da liegt die Komplexität aber in oidc selbst begraben und betrifft somit vermutlich die beiden zuvor genannten ebenfalls.

Das linux Magazin hatte vor kurzem eine zweiteilige Einführung in Keycloak in der auch die konkreten Anwendungsfälle beleuchtet wurden. Im 2. Teil werden best practises bei der Konfiguration behandelt die aus Security Sicht sinnvoll sind.

Sind wohl online leider hinter ner Paywall zu finden.

PS: Authelia wurde bereits erwähnt, das Debugging warum bspw. ein redirect nicht statt findet hatte ich ebenfalls. Argocd überprüft die eigene oidc config und redirected den Request erst dann, wenn die redirect_uri auf sich selbst verweist um einen leak des tokens zu verhindern.
 
Ich weiß jetzt nicht genau wofür die letzten beiden Antworten hier gedacht waren, aber ich finde das Tool von @jmt schon sinnvoll (aufgrund der Beschreibung).

Es gibt viele Dienste die ein LDAP oder ähnliches verlangen/damit einfacher zu nutzen sind, aber keine eigene Administration dafür vorsehen. Jetzt kann man natürlich sagen, da gibt es viel und blah, aber was man für sich selbst wirklich benötigt, bleibt dann jedem selbst überlassen, und ein Projekt, dass sehr klein ansetzt, kann auch jemandens Usecase bedienen, bzw. dafür sorgen, dieses zu erweitern.
 
medV2 schrieb:
Es gibt viele Dienste die ein LDAP oder ähnliches verlangen/damit einfacher zu nutzen sind, aber keine eigene Administration dafür vorsehen. Jetzt kann man natürlich sagen, da gibt es viel und blah, aber was man für sich selbst wirklich benötigt, bleibt dann jedem selbst überlassen, und ein Projekt, dass sehr klein ansetzt, kann auch jemandens Usecase bedienen, bzw. dafür sorgen, dieses zu erweitern.
Zum Vergrößern anklicken....
Ist das heute wirklich noch so? In meinem beruflichen Kontext sehe ich Tools die auf LDAP aufbauen eigentlich nur noch im Kontext der OT wo die Entwicklung traditionell sehr langsam fortschreitet und Security anders gekapselt wird. In der IT Welt ist es bei uns zumindest schon lange eine feste Anforderung dass eine LDAP Integration von Anwendungssoftware nicht mehr passiert. Die Securityvorteile das durch z.B. OIDC zu entkoppeln liegen ja auf der Hand.

Gleichwohl braucht man, wie ich schrieb, auch wenn man am Ende entscheidet seine Anwendungen mittels OIDC zu authentifizieren, mutmaßlich trotzdem noch den LDAP, aber eben nur noch als Backend fürs OIDC und eben nicht mehr um alle möglichen Anwendungen direkt darin rumschmieren zu lassen.

Insofern ist ein Tool um LDAP Nutzerverwaltung zu machen schon Sinnvoll - hier muss man dann aber schon so ehrlich sein und sagen dass das Tool von @jmt da halt auch was den LDAP Server und das Schema angeht sehr Opinionated ist. Mit meinem Directory Layout z.B. wäre es nicht kompatibel, aber das ist ja okay ;-)

Glücklicherweise gibt es Tools um LDAP Directories zu verwalten ja aber wie Sand am Strand. Apache Directory Studio fiele mir da z.B. sofort ein, oder auch ganze Toolsuiten in die man greifen kann, wie die Open Identity Platform usw.
 
Was diskutiert Ihr hier eigentlich? Ich habe ein kleines, auf OpenBSD zugeschnittenes Tool geschrieben, das meinen Bedarf abdeckt. So etwas habe ich nicht gefunden, also habe ich es gebaut. Das alleine hat auch Spaß gemacht. Natürlich gibt es jede Menge Tools, die mein "Problem" auch abdecken. Wenn man mit dem ganzen Zoo, den man dazu bekommt, leben kann, dann ist doch alles ok. Ich wollte und will mit Weft gar nicht mit diesen Tools konkurrieren. Und wenn man OCID möchte, dann kann man auch Tools wie Pocket ID verwenden. Vielleicht teste ich das mal, aber auch das ist bei Weft erst einmal out of scope.
Ldapd ist in OpenBSD, ich wollte eine grafische Benutzerverwaltung und die Möglichkeit, dass meine Benutzer einfach ihr Passwort ändern können. Genau das ist Weft.
 
Für den kleinen Heim-Setup würde ich die Grenze eher pragmatisch ziehen: LDAP als simples internes Verzeichnis ist ok, solange die Dienste direkt LDAP sprechen und du das Schema bewusst klein hältst. OIDC würde ich erst davor setzen, wenn mehrere Webdienste es sauber unterstützen oder du MFA/SSO wirklich brauchst. Sonst holt man sich mit Reverse-Proxy, Redirect-URIs und Token-Debugging schnell mehr bewegliche Teile rein als Nutzen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben