Authentik – Single-Sign-On (SSO) im Homelab

… und eine neue Art, LXC auszurollen. Neulich bin ich über die Proxmox-Helper-Skripte „gestolpert” und habe festgestellt, dass dies eine sehr gute Methode ist, um LXC für bestimmte Aufgaben vorzubereiten. Mit nur einer Befehlszeile kann ich einen Container erstellen und die gewünschte Anwendung installieren. Ich zeige dir das einfach mal an einem Beispiel. Was ich für Authentik ohnehin benötige, ist ein Debian-LXC mit installiertem Docker und Docker Compose. Das passende Skript findest du hier.

Alles, was du also tun musst, ist, statt auf „Create CT” zu klicken, die Kommandozeile (Shell) eurer Proxmox-Installation zu starten und folgende Zeile einzugeben – gefolgt von der ENTER-Taste:

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/docker.sh)"

Umgehend öffnet sich ein Menü. Dort kannst du wie auch sonst in der WebGUI die passenden Container-Einstellungen anpassen oder einfach mit den Standard-Einstellungen beginnen.

Und dann beginnt die Magie. Der CT wird erstellt und auf den aktuellen Stand gebracht. Anschließend werden Docker und Docker Compose installiert.

Wechselst du dann in die Shell des neu erstellten CT, wirst du direkt mit dem (angepassten) Login-Screen begrüßt. Schneller geht es kaum.

Im o. a. Beispiel bin ich letztendlich doch den Weg über „Advanced Settings” gegangen, weil ich Dinge wie den Hostnamen von vornherein anpassen wollte. Aber nun zum eigentlichen Thema: Authentik.

Zunächst eine kurze Erläuterung, was dein Vorteil mit Authentik ist:

Authentik ist ein selbst gehosteter, quelloffener Identity Provider (IdP), der es dir ermöglicht, die Benutzer-Authentifizierung und -Autorisierung zentral zu organisieren – und das ohne Abhängigkeit von externen Cloud-Diensten. In deinem Homelab steht Authentik typischerweise zwischen einem Nutzer und allen Anwendungen, die du betreibst. Wenn du auf Portainer, Proxmox, dein NAS-Webinterface oder auch selbst gebastelte Tools zugreifen willst, „fragt” dich Authentik immer nach deiner Identität. Unterstützt werden gängige Protokolle wie OAuth2, SAML oder LDAP, sodass zahlreiche Apps und Dienste im Homelab angebunden werden können – egal, ob sie modern oder oldschool sind.

Single Sign-On (SSO) sorgt dafür, dass du dich nur einmal anmelden musst – und dann überall im Homelab sofort durchstarten kannst. Das ist nicht nur luxuriös faul, sondern auch handfest praktisch:

Ein Login – alles offen: Schluss mit dem Klick-Marathon durch zig Login-Masken. Einmal authentifiziert, bist du für alle angebundenen Dienste freigeschaltet .
Passwort-Müdigkeit adé: Du musst dir nur noch ein (hoffentlich echt gutes!) Passwort merken. Das senkt die Versuchung, überall das gleiche (oder schlimme, einfache) Passwort zu nutzen – und steigert so die Sicherheit spürbar.
Feinschnitt für Zugriffsrechte: Mit einem IdP kannst du steuern, wer auf was Zugriff erhält. Gerade im Homelab z.B. für Mitbewohner, Familie oder mehrere Nutzer praktisch.
Zentrale Kontrolle: Ein Nutzer ist kompromittiert? Neue Apps sollen nur für bestimmte Leute sichtbar/erreichbar sein? Alles lässt sich an einer zentralen Stelle fix und nachvollziehbar managen.
Weniger Passwort-Hölle, mehr Übersicht: Besonders, wenn du mehr als drei Dienste betreibst oder mal etwas testest, verlierst du nie den Überblick über zig lokale Accounts und Passwörter.

Das Thema Single Sign-On (SSO) bringt mich zurück zum allerersten Beitrag hier im Blog. Authentifizierung, Autorisierung und Accounting (AAA). SSO ist ein Authentifizierungsverfahren, bei dem sich ein Nutzer nur einmal anmeldet und anschließend auf mehrere Dienste und Anwendungen zugreifen kann, ohne sich erneut authentifizieren zu müssen (Autorisierung).

Wie funktioniert Single Sign-On in der Praxis?

1. Zentrale Anmeldung:
Der Nutzer meldet sich an einer zentralen Stelle (dem sogenannten „Identity Provider“ – IDP, z.B. Authentik, Keycloak, Azure AD) an.

2. Token-Vergabe:
Nach erfolgreicher Authentifizierung erhält der Nutzer ein digitales Token (z.B. SAML, OAuth2, OpenID-Connect), das seine Identität und ggf. seine Berechtigungen belegt. Aus technischer Sicht sind die Token Teil der URL, Cookies oder POST-Daten, bei Anwendungen hinter einem Proxy definitiv Teil des HTTP(s)-Header. Das führt SSO hinter einem Proxy auch immer vermehrt zu Troubleshooting 🙂

3. Zugriff auf Anwendungen (Authentifizierung):
Wird eine angebundene Anwendung („Service Provider“, z.B. Paperless-ngx, Nextcloud, Synology NAS) aufgerufen, prüft diese, ob ein gültiges SSO-Token vorliegt:

Falls nicht, wird der Nutzer an den IDP weitergeleitet („Redirect“), loggt sich ein und bekommt das Token.

Mit Token kann die Anwendung die Identität/des Nutzers prüfen, ohne eigene Anmeldung zu verlangen.

4. Single Logout (optional):
Bei SSO kann auch der Logout zentral gesteuert werden, sodass der Nutzer aus allen angebundenen Anwendungen ausgeloggt wird.

Wie und wo kann ich Nutzer „verrechten“ (Rechtevergabe = Autorisierung)?

Auch hier gibt es diverse Möglichkeiten, die ich in der Grafik dargestellt habe.

A) Rechtevergabe im Identity Provider (zentral):

Die Benutzer werden zentral im IdP gepflegt und verwaltet. Dabei müssen die Benutzer nicht ausschließlich lokal angelegt werden. Es ist durchaus praktikabel, die Benutzerdatenbank auszulagern bzw. anzubinden (z. B. ein externer LDAP-Server oder ein bestehendes Microsoft Active Directory). Rollen, Gruppen oder Attribute werden im IdP festgelegt und als „Claims“ im Token an die Anwendungen übergeben (z. B. „is_admin“, „department: HR“). Die Anwendungen lesen diese Claims und vergeben die Berechtigungen entsprechend (z. B. Admin-Oberfläche freischalten, Zugriff verbieten etc.).

Vorteil: einfache, einheitliche Verwaltung aller Nutzerrechte an einem Ort.

B) Rechtevergabe in der Anwendung (dezentral):

Anwendungen können zusätzlich eigene, interne Rechte- oder Rollenkonzepte besitzen, in die sie beispielsweise den Benutzernamen oder die Gruppen aus dem SSO-Token mappen. Die Rechteverwaltung läuft dann in der Anwendung weiter, während der SSO-Dienst nur für die Authentifizierung sorgt und Informationen übergibt.

C) Kombination:

Viele Unternehmen nutzen eine Mischung aus beiden Optionen. Grobe Rollen/Gruppen werden im IdP gepflegt. Die Feinsteuerung (z. B. konkrete Dateizugriffsrechte) bleibt in der Anwendung.

Wo vergibst du die Rechte?

Die IdP-Verwaltung kann im Web-Frontend oder über APIs/CLI des IdP erfolgen (z. B. Authentik-Adminpanel unter „Benutzer“, „Gruppen“, „Policies“, „Entitlements“).

Anwendung: In der Benutzerverwaltung/Freigabeverwaltung der jeweiligen Anwendung.

Wichtig zu wissen

SSO sorgt primär für eine zentrale Authentifizierung (Wer bist du?). Die Autorisierung (Was darfst du?) kann dagegen zentral, dezentral oder kombiniert abgebildet werden.

Änderungen der Rechte im IdP wirken sich sofort auf alle angebundenen Anwendungen aus, die darauf reagieren.

Ob die Rechte korrekt zugewiesen werden, hängt davon ab, wie gut IdP und Anwendung integriert sind und ob die Anwendung die Gruppen/Rollen aus dem Token beachtet. (OPNsense ist ein „Negativbeispiel”, da kannst du zwar Authentik als LDAP-Provider „missbrauchen”, aber das hat allein wegen des fehlenden Redirects wenig mit echtem SSO zu tun.)

Wie funktioniert das aus technischer Sicht? Grundsätzlich meldest du dich bei deinem IdP (hier Authentik) an. Die Webanwendung wird entsprechend konfiguriert, sodass sie zusätzlich einen IdP zur Benutzeranmeldung erlaubt (die IP-Adresse und das Protokoll des IdP werden quasi übergeben). Den Rest übernimmt der IdP. Nach der einmaligen Authentifizierung beim IdP kannst du dich bei allen Web-Anwendungen, die SSO unterstützen, mit einem Klick entweder mit deiner E-Mail-Adresse oder einem Benutzernamen anmelden, ohne dich erneut authentifizieren zu müssen. Sollte der Benutzer in der Webanwendung noch gar nicht existieren, wird er abhängig von der Anwendung durch den IdP angelegt. Im Anschluss muss er jedoch einmalig manuell verrechtet werden, um auf die Ressourcen der Anwendung zugreifen zu können. Die Benutzerdatenbank liegt also zukünftig lokal im IdP und wird auch dort gepflegt. Sie kann aber auch durch eine LDAP-Anbindung ausgelagert werden, beispielsweise an ein Microsoft Active Directory.

„Authentik verleiht dem eigenen Homelab einen Hauch von Enterprise-Feeling – aber mit maximaler Datensouveränität. Wer gerne mehrere Webapps, Container-Interfaces und Tools jongliert, will schon nach kurzem Test nie wieder zurück ins Passwort-Chaos!“

Bei Docker habe ich mir angewöhnt, die Konfigurationen für die einzelnen Instanzen immer in ein eigenes Verzeichnis auszulagern (nie im Homeverzeichnis des Benutzers). Dazu erstelle ich unter /opt ein neues Verzeichnis, wechsle dorthin und lade das docker-compose.yaml von Authentik herunter.

mkdir /opt/authentik
cd /opt/authentik
wget https://goauthentik.io/docker-compose.yml

Als Nächstes passt du die Umgebungsvariablen für Authentik an und beginnst mit der Generierung von Passwörtern.

echo "PG_PASS=$(openssl rand -base64 50 | tr -d '\n')" >> .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env
echo "AUTHENTIK_ERROR_REPORTING__ENABLED=true" >> .env

Dadurch wird eine neue Datei namens .env im Verzeichnis /opt/authentik erstellt. Öffne diese direkt mit dem Editor nano und bearbeite sie, da wir noch einige Einstellungen für den E-Mail-Versand hinterlegen müssen. Das ist nötig, damit beispielsweise die Option „Passwort vergessen” später auch funktioniert.

# SMTP Host Emails are sent to
AUTHENTIK_EMAIL__HOST=localhost
AUTHENTIK_EMAIL__PORT=25
# Optionally authenticate (don't add quotation marks to your password)
AUTHENTIK_EMAIL__USERNAME=
AUTHENTIK_EMAIL__PASSWORD=
# Use StartTLS
AUTHENTIK_EMAIL__USE_TLS=false
# Use SSL
AUTHENTIK_EMAIL__USE_SSL=false
AUTHENTIK_EMAIL__TIMEOUT=10
# Email address authentik will send from, should have a correct @domain
AUTHENTIK_EMAIL__FROM=authentik@localhost

Welche Einstellungen du hier genau hinterlegen musst, erfährst du bei deinem E-Mail-Anbieter. Im Grunde sind es dieselben Einstellungen wie in deinem sonstigen E-Mail-Programm.

Standardmäßig ist die Authentifizierung über die Ports 9000 oder 9443 erreichbar. Du kannst das mit den folgenden zwei Zeilen in deiner .env anpassen, wenn du möchtest. Da ich meine Webdienste hinter einem HAProxy laufen habe, bleibe ich bei den Standard-Ports und verlinke diese später im HAProxy.

COMPOSE_PORT_HTTP=80
COMPOSE_PORT_HTTPS=443

Mit dem Befehl docker-compose up -d startest du die Docker-Instanz. Anschließend kannst du die WebGUI über http://<IP>:9000 oder https://<IP>:9443 aufrufen.

Da wir zu diesem Zeitpunkt das Passwort für den Standard-Admin „akadmin” noch nicht kennen, beginnen wir mit http://:9000/if/flow/initial-setup/ in der Adresszeile des Browsers (beachte den Slash ganz am Ende der URL, sonst funktioniert es nicht). Dort angekommen, kannst du ein Passwort festlegen und dich anschließend einloggen.

Erwartungsgemäß ist es zu Beginn sehr übersichtlich, da noch keine Anwendungen hinterlegt sind. Was wir zuerst machen wollen, ist, für mehr Sicherheit zu sorgen. Dazu erstellen wir einen neuen Admin (in meinem Besipiel namens Hans Dampf (hdampf)) und deaktivieren, sobald dieser passend verrechtet ist, den Standard-Admin. Denn ich möchte nicht, dass, sobald ich Authentik öffentlich (also im Internet) erreichbar habe, möglichen Angreifern durch einen bekannten Benutzernamen (akadmin) die halbe Miete für einen Brute-Force-Angriff zum Erraten der Anmeldedaten geliefert wird.

Klicken wir also zuerst oben rechts auf „Verwaltungsoberfläche …”.

Links auf Directory -> Users -> Erstellen

… und legen dann einen neuen Nutzer an. Anschließend klicken wir auf das kleine Dreieck beim Nutzer und legen über „Passwort festlegen” ein neues Passwort für ihn fest. Du kennst die Regeln: Mindestens 12 Zeichen (bei mir sind es immer deutlich mehr), Groß- und Kleinbuchstaben, Ziffern und Sonderzeichen.

Danach klickst du links unter Directory auf Groups / authentik Admins….

Dort dann auf Benutzer und Bestehenden Benutzer hinzufügen.

Wähle dort deinen neu erstellten Admin aus und füge ihn hinzu. Dann loggst du dich aus und mit deinem neuen Admin-Namen (hier „hdampf”) erstmalig ein.

Wenn das funktioniert, gehst du direkt zur Verwaltungsoberfläche > Directory > Users > akadmin und deaktivierst diesen Account. Damit ist das Nötigste getan, um ein Login mit dem Standard-Admin-Konto zu unterbinden.

Logins konfigurieren

Das Hinzufügen/Konfiguration einer Anwendung folgt immer wieder demselben Muster:

Anwendung im IdP erstellen
Provider erstellen/auswählen
Anwendung selbst für SSO konfigurieren (sprich IP/FQDN des IdP hinterlegen) und aktivieren
ggf. IdP-Nutzer in der Anwendung die erforderlichen Rechte geben

Schauen wir und das an Hand von ein paar Beispielen an:

Synology NAS

Klicke in der Verwaltungsoberfläche auf Applications / Applications / Create with Provider und wähle einen beschreibenden Namen:

Wähle dann, wie in der Dokumentation beschrieben, oAuth2 als Provider für das Synolgy NAS aus.

Bei Auth-Flow hast du 2 Möglichkeiten. Explicit bedeutet, das dir ein Warnhinweis bei der Anmeldung angezeigt wird, bei implicit wird dies nicht. Entscheide selbst, ob du das brauchst.

Wichtig! Kopiere die beiden Einträge „Client ID” und „Client Geheimnis” in eine Textdatei, da du beide bei der Konfiguration auf der NAS gleich brauchen wirst. Das „Client Geheimnis” wird dir kein zweites Mal angezeigt..

Wähle unter den erweiterten Protokolleinstellungen im Betreffmodus „Basierend auf der E-Mail-Adresse des Benutzers”. In diesem Feld wird angezeigt, wie dein Benutzername für die Anwendung aufgebaut ist. Der Benutzername kann also eine E-Mail-Adresse, ein Name, eine Nummer usw. sein. Solltest du hier die falsche Auswahl treffen, wirst du zwar in der Applikation angemeldet, verfügst aber über keinerlei Rechte, um dort etwas zu machen.

Unter „Bindings” legst du fest, welche Benutzer in Authentik Zugriff auf die Applikation haben sollen, d. h. in einer Familie legst du fest, wer grundsätzlich auf die NAS zugreifen darf und wer nicht. Die weitere Differenzierung, zum Beispiel wer auf welchen Ordner zugreifen darf, regelst du auf der NAS.

Hinweis: Bei der Synology NAS muss der Benutzer bereits auf der NAS angelegt sein. Die NAS nutzt Authentik nur zur Authentifizierung und legt den Nutzer nicht automatisch an.

Du kannst eine bestehende Richtlinie, Gruppe oder Benutzer auswählen. Letztendlich erhält diese Zugriff auf die Ressource (im Beispiel ist dies der Benutzer „hdampf”).

Sichere die erstellten Bindings und schließe die Konfiguration ab:

Um später neue Nutzer hinzuzufügen, klickst du unter „Applikation” auf die entsprechende Anwendung und dort auf den Reiter „Policy”. Unter „Gruppen/Nutzer-Binding” kannst du auch regeln, was der jeweilige Nutzer bezüglich der Anwendung in Authentik machen darf, also ob er etwas sehen, löschen oder ändern darf. Dies hat jedoch nichts mit den Rechten auf der NAS zu tun, sondern betrifft lediglich die Möglichkeit, die SSO über Authentik für die App zu nutzen.

Kommen wir nun zur zweiten Seite der Konfiguration. In Authentik sind wir soweit fertig.

Logge dich auf deiner Synology NAS als Administrator (oder als Benutzer mit Admin-Rechten) ein. Ich bevorzuge lokale Administratoren mit einem anderen Benutzernamen als dem Standard-Admin und alle Remote-Nutzer haben nur Benutzerrechte. Mehr braucht man für den Betrieb und die Nutzung i. d. R. ja auch nicht. Überleg mal, wie selten man administrativ eingreifen muss.

In der Systemsteuerung klickst du auf „Domain/LDAP/SSO-Client”. Aktiviere dort die Optionen SSO standardmäßig auf der Anmeldeseite anzeigen und OpenID Connect als SSO-Dienst.

Weiter geht es dann mit den OICD-Einstellungen. Sobald du OICD als Profil ausgewählt hast, kannst du auch den Rest konfigurieren:

Kontotyp: Domain/LDAP/lokal
Name: authentik
Well-know-URL: findest du in Authentik unter Applications / Provider / Provider für Synology NAS / OpenID-Konfigurations-URL (rechts oben der erste Eintrag)
Anwendungs-ID: deine vorhin in die Textdatei kopierte Client ID (der kürzere der beiden Zeichenketten)
Anwednungsgeheimnis: dein vorhin in die Textdatei kopierte Client Secret
Umleitungs-URL: die URL die du in in der Authentic-Provider-Konfig hinter strict eingetragen hast, also die korrekte URL zu deiner NAS (keine IP-Adressen, das macht nur Ärger)
Autorisierunsgbereich: openid profile email
Benutzeranspruch: prefered_username

Mit einem Klick auf „Speichern und übernehmen” kannst du die Konfiguration sichern und dich abmelden. Ab jetzt hast du zwei Möglichkeiten, dich an der NAS anzumelden: die alte „Bei DSM anmelden” und die voreingestellte SSO-Authentifizierung.

Mit einem Klick auf den blauen Button gelangst du zur SSO-Anmeldung. Da ich in Authentik in diesem Fall noch mit dem Nutzer „hdampf” angemeldet bin, wird mir dieser auch direkt vorgeschlagen. Der Sinn besteht ja darin, dass ich mich einmal bei Authentik anmelde und alle anderen Anmeldungen passwortlos sind.

Wenn du in dem Schritt weiter oben implicit statt explicit auswählst kommt genau dieses Hinweisfenster nicht mehr, dann wirst du mit einem einzigen Klick einfach angemeldet.

Wenn es den passenden Nutzer bereits auf der NAS gibt (siehe Hinweis oben), bist du automatisch eingeloggt.

Paperless

Schauen wir uns dasselbe „Spiel” in Paperless an. Auch hier müssen wir gemäß der Dokumentation wieder dem Dialog folgen: Authentic/Verwaltungsoberfläche/Applications/Application/Create with Provider.

Nachdem du einen aussagekräftigen Namen vergeben hast, wählst du im folgenden Schritt „OAuth2/OpenID Connect” aus. Kopiere auch hier erneut die Client-ID und das Client-Secret (sowie den Slug) in eine Textdatei (die du in Paperless-ngx brauchst).

Die Redirect-URL hinter strict ist diesmal etwas aufwendiger aufgebaut, hinter deiner eigentlichen URL für Paperless muss noch /accounts/oidc/authentik/login/callback/, bei mir also:

https://paperless.internally.duckdns.org/accounts/oidc/authentik/login/callback/

Dann geht es direkt mit den Bindings weiter (es sind keine weiteren Protokolleinstellungen erforderlich, da die drei standardmäßig ausgewählten Scopes ausreichen). Wenn du hier keine Benutzer angibst, können theoretisch alle deine Authentik-Nutzer Zugriff auf die Applikation erlangen, d. h., es gibt keine Einschränkungen seitens Authentik.

Weiter geht es mit der Konfiguration in Paperless. Hier musst du unterscheiden, ob du Paperless als Standalone-Version oder als Docker-Variante installiert hast. Siehe dazu die Dokumentation. In meinem Fall ist es Docker, sodass ich die docker-compose.yaml mit nano bearbeiten muss. Im Abschnitt „Services/Webserver/Environment” muss ich folgende Zeilen einfügen (da, wo die anderen PAPERLESS_*-Variablen stehen, also vor „gotenberg:”): Ersetze die Client_ID und das Client Secret durch die beiden Zeichenketten, die du zuvor kopiert hast, und passe die Server_URL an. Kopiere am besten die komplette OpenID-Konfigurations-URL aus Authentik, wie im Beispiel der Synology NAS, hier in diesen Value:

    PAPERLESS_APPS: allauth.socialaccount.providers.openid_connect
    PAPERLESS_SOCIALACCOUNT_PROVIDERS: >
        {
          "openid_connect": {
            "APPS": [
              {
                "provider_id": "authentik",
                "name": "Authentik",
                "client_id": "<Client ID>",
                "secret": "<Client Secret>",
                "settings": {
                  "server_url": "<OpenID-Konfigurations-URL>"
                }
              }
            ],
            "OAUTH_PKCE_ENABLED": "True"
          }
        }

Anschließend startest du Paperless-ngx mit dem Befehl docker container up -d neu. Wenn du dich bei Paperless-ngx abmeldest, wird auch hier das neue Anmeldefenster angezeigt.

Du kannst dich dann entweder mit einem bestehenden Nutzer oder mit einem neuen Nutzer (hier wieder „hdampf”) über Authentik anmelden. Im letzteren Fall wirst du durch Authentik authentifiziert und Paperless führt dich anschließend durch den Registrierungsprozess des neuen Nutzers.

Anschließend bist du zwar als neues Nutzer eingeloggt, hast aber keinerlei Rechte:

Dazu musst du dich als Paperless-Admin einloggen und dem Nutzer die entsprechenden Rechte gewähren.

….zum Beispiel das Recht eigene Dokumente hinzuzufügen, zu bearbeiten, zu löschen oder anzuzeigen.

Ein Browser-Reload als angemeldeter „Hans Dampf“ reicht dann aus, um die Rechte nutzen zu können:

Obacht bei Paperless! Solange Dokumente keinem Eigentümer zugeordnet sind, sind sie für alle angemeldeten Nutzer sichtbar (hier sieben Dokumente).

Was passiert eigentlich, wenn ich Hans Dampf in Paperless nachträglich deaktiviere?

Wie du siehst, wird er zwar über Authentik authentifiziert, aber von Paperless nicht autorisiert. Deshalb hat er trotz Anmeldung keine Rechte auf dem Zielsystem.

Wazuh

Wazuh ist ein Beispiel dafür, dass du das Rollen-/Rechte-Mapping in Authentik erledigen musst. Wenn du dich in Wazuh einloggst (standardmäßig mit „admin”) und zu der Benutzerverwaltung unter Server Management/Security wechselst, wirst du feststellen, dass es dort nur zwei technische Nutzer gibt, aber keinen, mit dem du dich eingeloggt hast. Du musst wissen, dass diese beiden Nutzer für die API-Verwaltung zuständig sind, aber nicht für die Web-Oberfläche.

Alle GUI-Admins werden in der internen Datenbank des Indexers verwaltet. Dazu gehst du zu „Indexer Management” > „Security” > „Internal Users”.

Diese Nutzer werden alle automatisiert während der Installation angelegt. Wichtig ist, dass der Benutzer „admin” (Standard-Admin) die Rolle „admin” hat. Genau diese Rolle müssen wir letztendlich über das Zusammenspiel zwischen Authentik und Wazuh verrechten.

Schritt für Schritt: Wir beginnen wieder bei Authentik.

Zunächst erstellen wir eine neue Benutzergruppe für Wazuh in der Verwaltungsoberfläche unter „Directory” > „Groups” > „Erstellen”. Vergib hier lediglich einen Namen (sonst keine Änderungen!) und klicke auf „Erstellen”.

Klicke anschließend auf den Namen der neu erstellten Gruppe.

… und fügst im Reiter „Benutzer” über „Bestehenden Benutzer hinzufügen” einen Nutzer hinzu (hier „hdampf”).

Weiter geht es mit dem Rollenmapping unter der Verwaltungsoberfläche > Customization > Property Mappings > Erstellen.

Wähle hier in der Liste den Eintrag SAML Provider Property Mapping aus und klicke auf Weiter.

Mache dort folgende Einstellungen:

Name: etwas beschreibendes
SAML-Attributsname: Roles
Name: leer lassen
Ausdruck:

if ak_is_group_member(request.user, name="wazuh-administrators"):
   yield "wazuh-admin"

Nachdem du auf „Beenden” geklickt hast, musst du hier ebenfalls eine Applikation mit Provider anlegen. Klicke dazu in der Verwaltungsoberfläche auf Applications > Applications > Create with Provider.

Wähle einen Namen/Slug und weiter gehts:

Wähle den SAML-Provider aus:

Der Name ist bereits vorausgewählt, deine Aufgabe ist es, die URL anzupassen. Dazu musst du den String /\_opendistro/\_security/saml/acs hinter die eigentliche Wazuh-URL setzen, siehe auch mein Beispiel. Austeller ist wazuh-saml und das Privider Binding erfolgt mit „Post“

Stelle sicher, dass dein neu erstellter Property Mapping unter Eigenschaftszuordnung auf die rechte Seite zu Selected User Property Mappings wandert.

Bindings musst du übrigens nicht unbedingt konfigurieren. Wenn du das nicht tust, muss dir aber klar sein, dass jeder Nutzer, der sich in Authentik authentifiziert, am Ende Admin-Rechte in Wazuh hat. Da du das nicht willst, musst du hier die Nutzer oder Gruppen einschränken (wie das geht, habe ich anderweitig beschrieben).

Als letzten Schritt gehst du in Authentik auf „Application/Providers/Provider for Wazuh” und lädst die XML-Datei herunter.

Weiter geht es mit der Konfiguration von Wazuh, die nur auf der Kommandozeile möglich ist. Kopiere zunächst die XML-Datei von eben nach /etc/wazuh-indexer/opensearch-security/wazuh_authentik_meta.xml. Du kannst die Datei auch mit dem Befehl nano /etc/wazuh-indexer/opensearch-security/wazuh_authentik_meta.xml erstellen und den Inhalt der XML-Datei dort einfügen.

Damit der Wazuh-Indexer auch Zugriff auf die Datei hat, musst du die Besitzverhältnisse anpassen.

chown wazuh-indexer:wazuh-indexer /etc/wazuh-indexer/opensearch-security/wazuh_authentik_meta.xml

Das ganze schaut jetzt so aus:

Danach erstellen wir einen Austauschschlüssel (Exchange Key), mit dessen Hilfe Authentik später mit Wazuh kommuniziert.

openssl rand -hex 32

Kopiere den String temporär in einen Texteditor – den werden wir gleich brauchen.

Jetzt geht es ans „Eingemachte”, aber zunächst erstellen wir Sicherheitskopien der folgenden vier Konfigurationsdateien:

cp /etc/wazuh-indexer/opensearch-security/config.yml /etc/wazuh-indexer/opensearch-security/config.yml.bak
cp /etc/wazuh-indexer/opensearch-security/roles_mapping.yml /etc/wazuh-indexer/opensearch-security/roles_mapping.yml.bak
cp /usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml /usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml.bak
cp /etc/wazuh-dashboard/opensearch_dashboards.yml /etc/wazuh-dashboard/opensearch_dashboards.yml.bak

Öffne die Datei im Editor deiner Wahl, passe die Sektion „basic_internal_auth_domain” an und füge direkt danach die Sektion „saml_auth_domain” ein. Folgende Zeilen sind besonders wichtig bzw. müssen ggf. angepasst werden:

authc: / basic_internal_auth_domain: / http_authenticator: / challenge: false
authc: / saml_auth_domain: / kibana_url: Hier muss dir URL zu deiner Wazuh-Instanz rein
authc: / saml_auth_domain: / kibana_url: exchange_key: hier muss der Austauschschlüssel rein, den du dir temporär im Texteditor gesichert hast

---
authc:
    basic_internal_auth_domain:
        description: "Authenticate SAML against internal users database"
        http_enabled: true
        transport_enabled: true
        order: 0
        http_authenticator:
            type: basic
            challenge: false
        authentication_backend:
            type: intern
    saml_auth_domain:
        http_enabled: true
        transport_enabled: false
        order: 1
        http_authenticator:
            type: saml
            challenge: true
            config:
                idp:
                    metadata_file: "/etc/wazuh-indexer/opensearch-security/wazuh_authentik_meta.xml"
                    entity_id: "wazuh-saml"
                sp:
                    entity_id: "wazuh-saml"
                kibana_url: "https://wazuh.internally.duckdns.org/"
                roles_key: Roles
                exchange_key: "<exchange key generated in step 1>"
        authentication_backend:
            type: noop

Danach führst du folgenes Skript aus:

export JAVA_HOME=/usr/share/wazuh-indexer/jdk/ && bash /usr/share/wazuh-indexer/plugins/opensearch-security/tools/securityadmin.sh -f /etc/wazuh-indexer/opensearch-security/config.yml -icl -key /etc/wazuh-indexer/certs/admin-key.pem -cert /etc/wazuh-indexer/certs/admin.pem -cacert /etc/wazuh-indexer/certs/root-ca.pem -h 127.0.0.1 -nhnv

Im Ergebnis sollte das so ausehen (Done with success):

Füge in der Datei /etc/wazuh-indexer/opensearch-security/roles_mapping.yml die Zeile „- wazuh-admin” unmittelbar vor „- admin” hinzu.

…und führst folgendes Skript aus:

export JAVA_HOME=/usr/share/wazuh-indexer/jdk/ && bash /usr/share/wazuh-indexer/plugins/opensearch-security/tools/securityadmin.sh -f /etc/wazuh-indexer/opensearch-security/roles_mapping.yml -icl -key /etc/wazuh-indexer/certs/admin-key.pem -cert /etc/wazuh-indexer/certs/admin.pem -cacert /etc/wazuh-indexer/certs/root-ca.pem -h 127.0.0.1 -nhnv

Dann öffnest du mit nano /etc/wazuh-dashboard/opensearch_dashboards.yml die nächste Konfigurationsdatei und fügst folgende Zeilen hinzu:

opensearch_security.auth.type: "saml"
server.xsrf.allowlist:
    [
        "/_opendistro/_security/saml/acs",
        "/_opendistro/_security/saml/logout",
        "/_opendistro/_security/saml/acs/idpinitiated",
    ]
opensearch_security.session.keepalive: false

Starte dann das Wazuh-Dashboard neu.

sudo systemctl restart wazuh-dashboard

Rufst du jetzt deine Wazuh-Instanz im Browser auf (und loggst dich ggf. zuvor aus), solltest du Folgendes sehen:

Ab jetzt kannst du dich mittels Single Sign On einloggen.

OPNsense

Auch OPNsense funktioniert wieder etwas anders, wie du der Dokumentation entnehmen kannst. OPNsense erfordert zwingend einen LDAP-Provider. Wenn du noch keinen hast, z. B. durch ein Microsoft Active Directory, kannst du auch Authentik zu einem LDAP-Provider heraufstufen. Warum auch nicht? Dort existiert ohnehin schon eine lokale Benutzerdatenbank.

Dazu gehst du auf Directory > Users > Dienstkonto erstellen und vergibst einen passenden Namen.

Das im folgenden Fenster angezeigte Passwort solltest du vorübergehend in eine Textdatei kopieren, da wir es später benötigen.

Klicke unter Applications/Provider auf Erstellen und wähle als Option den LDAP-Provider.

Unter Applications/Application klickst du auf Erstellen (ohne Provider!) und änderst Namen, Slug und Schnittstelle (Provider) ab.

Erstelle unter „Applications/Outpost” einen neuen Eintrag und wähle als Typ „LDAP” aus. Stelle sicher, dass die Anwendung LDAP auch als ausgewählte Anwendung aktiviert wurde.

Wechsle dann zu OPNsense und gehe zu System/Access/Servers.

Wie du siehst, war die Anmeldung zwar erfolgreich, der Benutzer hat aber sonst keine Berechtigungen auf der OPNsense. Jetzt hast du zwei Möglichkeiten.

Du erstellst manuell auf der OPNsense einen Benutzer mit demselben Namen und verrechtest ihn entsprechend.
Oder du synchronisierst dein LDAP mit dem Benutzerverzeichnis der OPNsense, am besten regelmäßig. Wie das geht, siehst du im folgenden Screenshot.

Wichtig! Wenn du als Standardgruppe „admins” einstellst, musst du in Authentik genau regeln, wer auf die Applikation OPNsense zugreifen darf. Denn jeder Nutzer, der sich jetzt über Authentik bei OPNsense einloggt, hat automatisch Admin-Rechte.

Denn wie ich weiter oben bereits erwähnt habe, kann die Verrechtung an mehreren Stellen im Setup erfolgen. Wie bereits erwähnt, ist HDampf jetzt ohne weiteres Zutun nach der Anmeldung über Authentik Admin auf der OPNSense verfügbar.

Update / Upgrade

Ein Update von Authentik erfolgt ebenfalls über docker compose:

cd /opt/authentik
docker compose pull
docker compose up -d

Vergiss aber nicht, auch deinen Debian-LXC immer auf Stand zu halten:

apt update && apt full-upgrade -y

ToDo:

Tutorial für Proxmox, Portainer, NetBox, Semaphore, Jellyfin, Plex, Home Assistant, Wazuh, WordPress, Bitwarden