© Konstantin Sleptsov / 123RF.com

Webanwendungen ohne eigene Benutzerverwaltung stülpt Authelia mit wenigen Handgriffen eine Zugangskontrolle über. Der nützliche Torwächter verlangt dazu allerdings einen Reverse Proxy.

Um das exklusive Fünf-Sterne-Restaurant vor Randalierern zu schützen, könnte man selbst am Eingang die Einladungen der Gäste kontrollieren, oder man engagiert einen Portier, der das galant übernimmt. Genau einen solchen Türsteher stellt Authelia für Webanwendungen bereit [1]. Damit reglementieren Sie den Zugriff auf Dienste, die keine eigene Zugriffskontrolle offerieren.

Dank der Software müssen zudem Entwickler in ihren eigenen Webanwendungen nicht mühsam und zeitaufwendig eine komplexe Benutzerverwaltung implementieren. Stattdessen schalten sie sie mit Authelia vor ihre Software. Es bietet von Haus aus eine Zwei-Faktor-Authentifizierung und ein Single-Sign-on (SSO). Damit genügt eine einmalige Anmeldung bei Authelia, um auf mehrere erlaubte Anwendungen zuzugreifen.

Authelia setzt voraus, dass die Kommunikation mit den zu schützenden Webanwendungen über einen Reverse Proxy läuft. Die Software klinkt sich dann wie in Abbildung 1 in diesen Reverse Proxy ein und kontrolliert dort wie der besagte Portier sämtliche eingehenden Anfragen.

Abbildung 1: Der Reverse Proxy legt jede eingehende Anfrage Authelia vor, das den Zugriff explizit freigeben muss.

Greift ein Nutzer mit seinem Browser auf eine Webanwendung zu, landet seine Anfrage zunächst beim Reverse Proxy, der sie direkt an Authelia zur Prüfung weiterreicht. Sofern der Browser zum ersten Mal anklopft, fehlt ihm ein von Authelia ausgestelltes Session Cookie. In diesem Fall leitet das Tool den Nutzer auf seine eigene Anmeldeseite um. Dort muss er sich zunächst mit Benutzernamen und einem Passwort ausweisen.

Doppelt gesichert

Die Anmeldedaten kann Authelia aus einer eigenen Benutzerdatenbank (eine simple YAML-Datei) holen oder einen LDAP-Server zurate ziehen. Administratoren dürfen den Aufbau der Passwörter über eine Policy vorgeben und etwa festschreiben, dass sie mindestens einen Großbuchstaben enthalten müssen. Damit Angreifer nicht einfach Passwörter durchprobieren können, lässt sich die Anzahl der Login-Versuche begrenzen. Erst nach einer vorgegebenen Wartezeit kann sich der Nutzer erneut anmelden. Deutlich effektiver wäre es, würde sich die Zeitspanne automatisch mit jedem falschen Passwort verlängern. Das beherrscht Authelia allerdings nicht.

Um die Hürde für Angreifer weiter zu erhöhen, setzt Authelia auf eine Zwei-Faktor-Authentifizierung. Als zweiter Faktor dienen wahlweise One-Time-Passwörter, wie sie zum Beispiel der Google Authenticator erzeugt, Push-Nachrichten auf das Mobiltelefon oder hardwarebasierte Systeme, die dem Standard FIDO2 WebAuthn folgen (Yubikey-USB-Sticks). Die Push-Nachrichten verlangen auf den Smartphones der Nutzer die App Duo Push von Cisco.

Nach der erfolgreichen Anmeldung übergibt Authelia dem Browser ein Session Cookie. Alle folgenden Anfragen legt der Reverse Proxy wieder Authelia vor. Da der Browser nun ein Session Cookie vorweisen kann, gibt Authelia dem Reverse Proxy grünes Licht, die Anfrage an die passende Webanwendung weiterzuleiten. Das Session Cookie gilt dabei standardmäßig zusätzlich für alle Subdomains der von der Anwendung kontrollierten Domain. Ein Sequenzdiagramm in der Authelia-Dokumentation [2] demonstriert den Ablauf: Bei der ersten Anfrage leitet Authelia den Browser auf eine eigene Anmeldeseite um.

Wegen dieses Ablaufs muss Authelia weder die Arbeitsweise der Webanwendungen kennen noch kann es die übertragenen Daten (in Form der Payloads) mitlesen. Das Tool selbst verarbeitet nur die Authentifizierungsinformationen. So lassen sich prinzipiell beliebige HTTP-basierte Dienste schützen, etwa die REST- und GraphQL-Schnittstellen von Microservices. Dabei arbeitet Authelia derzeit mit den Proxys aus der Tabelle “Unterstützte Proxies” zusammen. Explizit außen vor bleiben Apache und Microsofts IIS. Generell müssen alle Beteiligten per HTTPS kommunizieren, um das Abgreifen des Session Cookies zu verhindern.

Authelia erlaubt ein Single-Sign-on via Trusted Headers, was sowohl der Proxy als auch die Webanwendungen unterstützen müssen. Darüber hinaus tritt Authelia als OpenID-Connect-1.0-Provider auf, bei dem die Authentifizierung über Tokens läuft. Obwohl sich diese Funktion zu Redaktionsschluss noch in der Beta-Phase befand, stößt sie bereits auf großes Interesse. So planen die Entwickler von Owncloud Infinite Scale, Authelia als Open ID-Connect-Provider in ihre Groupware zu integrieren [3].

Regelwerk

Ein Team soll häufig nur Zugriff auf ausgewählte Seiten eines Wikis erhalten. Dazu legen Administratoren eine Liste mit Zugriffsregeln an, die Authelia mit jeder eingehenden Anfrage abgleicht. Dementsprechend dient die Software gleichzeitig als Access-Control-System.

Die Regeln hinterlegen Sie wie in Listing 1 im YAML-Format. Das Beispiel lehnt sich an die Online-Dokumentation an [4]. Es erlaubt allen Nutzern aus der Gruppe »hamburg« den Zugriff auf die Domain »wiki.example.com«, wobei der Pfad den unter »resources« angegebenen regulären Ausdruck erfüllen muss. Im Beispiel wären alle unter »wiki.example.com/project/hamburg/« erreichbaren Seiten zugänglich. Die Anfragen müssen aus dem Subnetz 192.168.2.0/24 stammen und dürfen nur GET- oder POST-Methoden verwenden.

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

Authelia ist in Go als kompaktes, ohne Installation direkt einsatzfähiges Binary ohne Abhängigkeiten implementiert. Den offiziellen Paketen auf Github liegen eine Systemd-Unit und eine Beispielkonfiguration als Vorlage bei. Die Entwickler empfehlen, ihren offiziellen Docker-Container zu nutzen, der nur rund 30 MByte Hauptspeicher beansprucht [5]. Darüber hinaus ist Authelia für den Betrieb in Kubernetes ausgelegt. Dort lassen sich mehrere parallel laufende Container starten, um das Tool gezielt nach Bedarf zu skalieren beziehungsweise hochverfügbar einzurichten. Für das schnelle Aufsetzen sorgt das offizielle Helm Chart.

Im produktiven Betrieb verlangt das Tool weitere Softwarekomponenten. So merkt es sich ausgeteilte Session Cookies im Hauptspeicher oder in einer Redis-Datenbank. Während der Arbeit erzeugte Protokollinformationen, Einstellungen und andere Daten wandern verschlüsselt in eine PostgreSQL-, MySQL- oder SQLite-Datenbank. Um die Identität neuer Benutzer zu verifizieren, schickt Authelia ihnen eine E-Mail. Dazu müssen Administratoren einen SMTP-Server bereithalten.

Fazit

Authelia eignet sich aufgrund seiner Arbeitsweise nicht für alle Anwendungsfälle. So ist die Software überfordert, wenn sich Microservices automatisch untereinander authentifizieren sollen. Zudem fehlen derzeit noch einige im Enterprise-Einsatz wünschenswerte Funktionen. Dazu zählt etwa eine Multi Domain Protection, die jedoch bereits auf der Agenda des Projekts steht.

Durch den einfachen Aufbau und die übersichtliche Konfiguration lässt sich Authelia schnell aufsetzen. Die Identitäts- und Access-Management-Software eignet sich daher für KMUs oder den nachträglichen Schutz der Web-Anwendungen einer Domain vor unbefugtem Zugriff. Vor allem Go-Entwickler können Authelia in ihre Anwendung integrieren und sich so eine eigene Benutzerverwaltung sparen. (csi)