Inhaltsverzeichnis

Technische Grundkonzepte von IAM (Identity and Access Management)
Installation von Authelia
Konfiguration von Authelia
Persönliche Meinung

⚠️

Dieser Post ist Teil einer vierteiligen Serie, die im Rahmen eines Universitätsprojekts entstanden ist. In ihr wird der Vorlesungsinhalt des Moduls „Entwicklung verteilter Systeme“ zusammengefasst und um drei Schwerpunkte erweitert, die den Aufbau dieses Blogs beschreiben sollen. Update: Diese Blog-Serie wurde mit 1.0 bewertet 🎉.

In der zunehmend digitalisierten Gegenwart gewinnt die sichere Verwaltung von Benutzeridentitäten und Zugriffsberechtigungen immer mehr an Bedeutung. Angesichts einer stetig wachsenden Anzahl an Online-Diensten, die sowohl von Einzelpersonen als auch von Organisationen genutzt werden, steigt der Bedarf an robusten und zuverlässigen Authentifizierungs- und Autorisierungssystemen. Im Zentrum dieses Beitrags steht Authelia, ein Open-Source Identity and Access Management (IAM) System. Authelia zentralisiert Authentifizierungs- und Autorisierungsprozesse auf einer einzigen Login-Seite. Dadurch ermöglicht es nicht nur eine detaillierte Kontrolle über Benutzerzugriffsrechte, sondern bietet auch Single Sign-On (SSO) Fähigkeiten. Mit SSO erhalten Nutzer:innen nur mit einer einzigen Anmeldung Zugang zu allen verbundenen Diensten, was die User-Experience erheblich verbessert. In diesem Beitrag wird näher darauf eingegangen, wie Authelia durch einen Reverse Proxy oder durch standardisierte Protokolle, wie SAML in bestehende Systeme eingebunden wird.

1. Technische Grundkonzepte von IAM (Identity and Access Management)

IAM steht für Identity and Access Management. Es ist ein umfassendes Konzept, das die Verwaltung der Identifizierung, Authentifizierung und Autorisierung von Benutzer:innen in einem Informationssystem umfasst. Im Kern dreht sich IAM darum, sicherzustellen, dass die richtigen Personen Zugriff auf die richtigen Ressourcen im richtigen Kontext haben.

Die Identifizierung ist der Prozess der Eindeutigkeit der Benutzenden in einem System, typischerweise durch einen eindeutigen Benutzernamen. Authentifizierung ist der Prozess der Bestätigung, dass ein Benutzender tatsächlich der ist, für den er sich ausgibt, typischerweise durch ein Passwort oder andere Formen der Bestätigung, wie biometrische Daten oder Zwei-Faktor-Authentifizierung. Autorisierung bezieht sich auf den Prozess der Bestimmung, welche Aktionen authentifizierte Benutzer:innen in einem System durchführen können, was in der Regel durch Rollen oder Berechtigungen geregelt wird.

1.1 Zwei-Faktor-Authentifizierung (2FA)

Zwei-Faktor-Authentifizierung, oft abgekürzt als 2FA, ist eine Methode zur Verbesserung der Sicherheit der Benutzerauthentifizierung, indem ein zusätzlicher Schritt zur Bestätigung der Identität des Benutzers hinzugefügt wird. Bei 2FA müssen Benutzende nicht nur etwas wissen (wie ein Passwort), sondern auch etwas haben (wie ein Mobiltelefon) oder etwas sein (wie ein Fingerabdruck), um die Identität zu bestätigen.

1.2 Benutzerspeicher und Identitäten

In jedem IAM-System, einschließlich Authelia, ist eine zentrale Speicherung und Verwaltung von Benutzeridentitäten notwendig. Es gibt zwei vorherrschende Modelle für das Speichern und Verwalten von Benutzerdaten in Authelia: Authelia Nutzer und LDAP-basiertes Benutzerverzeichnis.

Authelia Nutzer sind lokal im System oder in einer externen Datenbank abgelegt und repräsentieren individuelle Identitäten. Die Verwaltung dieser Nutzer erfolgt direkt über Authelia, was eine flexible Kontrolle über Zugriffsrechte und Berechtigungen ermöglicht.

Typischerweise verwenden Organisationen ein auf LDAP basierendes Verzeichnis wie das Microsoft Active Directory zur Verwaltung ihrer Benutzerkonten. Dieses Nutzerverzeichnis kann bei Authelia als Datenbank hinterlegt werden. Mittels LDAP (Lightweight Directory Access Protocol) können dann Nutzerinformationen abgerufen und entsprechende Zugriffsrechte vergeben werden.

1.3 Authentifizierungs- und Autorisierungsprotokolle (SAML, OAuth 2.0 und OIDC)

Bestimmte Protokolle müssen verwendet werden, um sicherzustellen, dass Authelia funktioniert und mit anderen Anwendungen oder Programmen verbunden ist. OIDC, SAML und OAuth 2.0 sind drei Beispiele solcher Protokolle. Sie bieten sichere Mechanismen zur Gewährung von Zugriffsrechten und zur Identitätsüberprüfung.

OAuth 2.0 ermöglicht Benutzer:innen einen sicheren delegierten Zugriff, indem es ihnen ermöglicht, Anwendungen den Zugriff auf ihre Informationen zu gewähren, ohne ihre Anmeldeinformationen preiszugeben. Ein Beispiel hierfür wäre, wenn ein Benutzender einer Anwendung wie Draw.io ermöglicht, auf seine Google Drive-Dateien zuzugreifen, um Diagramme zu importieren und zu speichern, ohne seine Google-Anmeldeinformationen direkt an Draw.io weiterzugeben.

Sowohl SAML als auch OIDC sind für die Bereitstellung von Identitäts- und Authentifizierungsmechanismen von entscheidender Bedeutung. SAML ist eine XML-basierte Methode zur Übertragung von Autorisierungs- und Authentifizierungsdaten zwischen Identitätsanbietern und Dienstanbietern. Auf der anderen Seite liefert OIDC grundlegende Benutzerprofilinformationen, indem es eine Identitätsschicht hinzufügt, eine Erweiterung von OAuth 2.0. Beide können verwendet werden, wenn sich ein Benutzender mit seinem Google-Konto bei einer Drittanbieter-Webseite anmeldet, bei der Google als Identitätsanbieter fungiert.

Sowohl SAML als auch OIDC sind in der Lage, SSO zu integrieren. Um auf mehrere Anwendungen oder Dienste zuzugreifen, verwenden Benutzer:innen eine einzige Anmelde-ID und ein Passwort. SSO ist ein Authentifizierungsverfahren.

Dies verbessert die Benutzerfreundlichkeit erheblich, indem es die Notwendigkeit entfernt, sich mehrere Anmeldeinformationen für verschiedene Dienste merken zu müssen. Ferner kann SSO die Sicherheit verbessern, indem es die Anzahl der Angriffspunkte reduziert, die ein potenzieller Angreifender ausnutzen könnte.

2. Installation von Authelia

Authelia lässt sich auf zwei Wegen installieren: als Binärdatei oder mittels Docker. Zwar gibt es eine ausführliche Installationsanleitung in der offiziellen Authelia Dokumentation [1], dennoch möchte ich der Vollständigkeit halber meine docker-compose zur Verfügung stellen:

authelia:
	image: authelia/authelia:latest
	container_name: authelia
	hostname: authelia
	restart: unless-stopped
	depends_on:
		- redis
	env_file:
		- /docker/authelia.env
	volumes:
		- /docker/authelia/config:/config
	networks:
		- authelia
	labels:
		- traefik.enable=true
		- traefik.docker.network=docker_authelia
		- traefik.http.routers.authelia.entrypoints=https
		- traefik.http.routers.authelia.rule=Host(`auth.sauna.re`)
		- traefik.http.routers.authelia.tls.certresolver=sauna
		- traefik.http.routers.authelia.middlewares=ratesec-chain@file
		- traefik.http.routers.authelia.service=authelia
		- traefik.http.services.authelia.loadbalancer.server.port=9091
		- com.centurylinklabs.watchtower.enable=true
redis:
	image: redis:alpine
	container_name: redis
	hostname: redis
	restart: unless-stopped
	env_file:
		- /docker/common.env
	volumes:
		- /docker/authelia/redis:/data
	networks:
		- authelia
	labels:
		- com.centurylinklabs.watchtower.enable=true

Mein Authelia-Stack (Ausschnitt der docker-compose.yml)

3. Konfiguration

3.1 Access Rules

Mit der erfolgreichen Installation von Authelia kann die individuelle Konfiguration beginnen. Der zentrale Punkt hierfür ist die Datei configuration.yml, in welcher sämtliche Anpassungen für Authelia vorgenommen werden. Die Zugriffssteuerungen, welche für ein Identitäts- und Zugriffsmanagement (IAM) charakteristisch sind, können zum Beispiel dort eingestellt werden. Administrator:innen legen detaillierte Zugriffsregeln fest und stellen sicher, dass Nutzer:innen nur die ihnen zugewiesenen Ressourcen erreichen können. Diese Regeln basieren auf verschiedenen Faktoren wie URL, Pfad, IP-Adressen und HTTP-Methoden (POST/GET). Hier ein beispielhaftes Regelwerk:

access_control:
  rules:
    - domain: dev.example.com
      resources:
        - '^/groups/dev/.*$'
      subject: 'group:dev'
      policy: two_factor
      methods:
        - GET
        - POST
      networks:
        - 192.168.1.0/24

Beispiel Access-Control Regel

Die Beispiel-Regel legt fest, dass eine Anfrage, die von einem Gerät aus dem Netzwerk 192.168.1.0/24 an die Domain dev.example.com gesendet wird, und den Pfad aufweist, der mit /groups/dev/ beginnt, und die entweder die HTTP-Methode GET oder POST verwendet, nur dann Zugriff erhält, wenn das benutzende Mitglied der Gruppe dev ist und sich erfolgreich durch eine Zwei-Faktor-Authentifizierung ausgewiesen hat.

3.2 Integration über Authentifizierungsprotokolle

Wie eine erfolgreiche Implementierung von Single Sign-On (SSO) über Authelia aussehen würde, kann im folgenden Video gesehen werden.

Hierbei wurde die interne Authentifizierung von Portainer durch den zentralisierten Authelia Login ersetzt. Mithilfe von OAuth wird der Authelia User im Portainer Benutzerverzeichnis automatisch autorisiert, hinzugefügt und seinen Rechten zugewiesen, ohne sich bei Portainer mit einem separaten Login anzumelden.

Jede weitere Anwendung, in die Authelia integriert wird, kann diese Funktionen wie Single Sign-On (SSO) nutzen. Es ist jedoch wichtig zu beachten, dass jede Anwendung auf ihre Weise verschiedene Authentifizierungsprotokolle wie SAML, OAuth und OIDC verwendet und unterstützt. Daher ist die Methode, mit der Single Sign-On (SSO) in jeder Anwendung implementiert wird, individuell und übersteigt den Rahmen dieses Beitrags. Es gibt jedoch Beispiele für die Umsetzung verschiedener Anwendungen in der Authelia-Dokumentation [2].

3.3 Integration über Forward-Auth-Header

Im Falle, dass kein Authorisierungsprotokoll wie OAuth, OICD oder SAML von der Anwendung unterstützt wird, stellt Authelia eine alternative Methode zur Verfügung, die mithilfe unterstützter Reverse-Proxys [3] implementiert werden kann: die sogenannte Forward-Auth-Methode.

Wenn eine Web-Anfrage an den Reverse-Proxy ankommt, leitet dieser die Anfrage an Authelia weiter und fügt einen Forward-Auth-Header hinzu. Authelia prüft dann, ob der Nutzer anhand der Informationen im Forward-Auth-Header authentifiziert ist, indem es ein bestimmtes Cookie im Forward-Auth-Header sucht. Wenn das Cookie nicht vorhanden ist, wird der Nutzer automatisch zum Login-Interface von Authelia weitergeleitet. Nach erfolgreicher Authentifizierung wird der Nutzer zu dem ursprünglich angefragten Webdienst weitergeleitet und es wird ein Authelia Session Cookie in seinem Browser hinterlegt. Dieses Cookie erübrigt weitere Anmeldungen des Nutzers bis zu seinem Ablauf und kann auch für andere Anwendungen, für die Authelia konfiguriert ist, genutzt werden.

Ein Praxisbeispiel für diese Methode wird im folgenden Video demonstriert, in dem das Admin-Login meines Blogs mit Authelia geschützt wird. Ghost unterstützt keine Authorisierungsprotokolle und daher wurde folglich eine SSO-ähnliche Funktionalität mithilfe von Forward-Auth-Headern implementiert. In dem Video sieht man, dass der Nutzer erst zum Authelia-Login geführt wird, wenn das Cookie nach dem Löschen nicht mehr im System vorhanden ist.

4. Persönliche Meinung

Mein persönlicher Eindruck von Authelia ist geteilt. Die Hürden und Herausforderungen bei der Einrichtung und Verwendung des Tools sollten nicht unterschätzt werden. Es ist ein anspruchsvolles Thema und es hat viele Anläufe benötigt, um es richtig zum Laufen zu bringen.

Authelia ist anfangs etwas komplex, aber es bietet für mich bedeutende Vorteile. Es vereinheitlicht Logins und erhöht die Sicherheit meiner Webdienste, indem ein zweiter Authentifizierung-Schritt implementiert wird. Die Integration mit Traefik ist einfach und fiel mir im Vergleich zu Alternativen wie Keycloak leichter. Zudem hat Authelia seine Stabilität und kontinuierliche Weiterentwicklung über die Jahre hinweg unter Beweis gestellt. Trotz der Einarbeitungszeit ist Authelia für mich persönlich eine ideale IAM-Lösung, die meine IT-Sicherheit verbessert.