Benutzerverwaltung

Flexible Authentifizierung in Web-Applikationen

| Autor / Redakteur: Cornelius Kölbel* / Stephan Augsten

Hinsichtlich der Authentifizierung sollte eine Web-Anwendung möglichst flexibel sein.
Hinsichtlich der Authentifizierung sollte eine Web-Anwendung möglichst flexibel sein. (Bild: Archiv)

Sichere Authentifizierung ist ein Muss bei der Entwicklung einer neuen Web-Applikation. Dies gilt für E-Shops und Dienstleistungsportale ebenso wie für Web-basierte Monitoring- oder Ticketing-Systeme.

Passwörter werden heutzutage besonders gesichert, bevor sie in einer Datenbank abgelegt werden. In der Regel wird zunächst der Prüfwert (Hash) errechnet und um eine zufällige Zeichenfolge erweitert (Salt). Wer noch sicherer gehen möchte, reichert das Passwort sogar noch vor der Hash-Berechnung mit zufälligen Zeichen an (Pepper).

Doch manchmal – wie in unserem Fallbeispiel – bringt eine Web-Applikation auch ihre eigene, neue Benutzerverwaltung ins Spiel. Dabei sind die Benutzer im Unternehmen oder die Accounts der Kunden in der Regel aber bereits an anderer Stelle vorhanden.

Und war da nicht was mit Passwörtern? In den letzten Jahren gab es häufig genug Schlagzeilen über den massenhaften Diebstahl und Missbrauch von derartigen Passwortdatenbanken. Auch eine Web-Applikation sollte also den Authentifizierungsprozess flexibel genug abbilden.

Benutzer müssen extern verwaltet werden können

Einige proprietäre Hersteller und Open-Source-Projekte haben das natürlich schon lange erkannt und bieten verschiedene Module oder Plug-ins, über die sich alternative Benutzerquellen ansteuern lassen. So vertrauen viele Web-Anwendungen eben nicht auf die eigene, interne Benutzerdatenbank, sondern bieten bspw. die Möglichkeit, einen LDAP-Server anzubinden.

In diesem Fall werden die Benutzer und ihre Berechtigungen im LDAP gepflegt und die Authentifizierung der Benutzer läuft gegen das LDAP-Passwort. So setzen dies zwei bekannte Cloud-Hosting-Lösungen um. Das erscheint erstmal sehr attraktiv, stößt allerdings bald an seine Grenzen, wenn man Benutzer eben nicht mehr mit einem einzelnen LDAP-Passwort authentifizieren möchte, sondern eventuell mit zwei Faktoren.

Auch lässt sich ein Single Sign-on über SAML oder OpenID Connect hiermit nicht einfach abbilden. In diesem Fall müsste ein komplettes Modul geschrieben werden, dass sich um das Benutzerobjekt, dessen Berechtigungen innerhalb der Applikation und die Authentifizierung mit zwei Faktoren oder im Falle von SSO die Authentifizierung gegen den Identity Provider kümmert.

Trennung von Benutzerverwaltung und Authentifizierung

Die Aufgaben, die bei dem Anmeldeversuch des Benutzers anfallen, sind im Wesentlichen:

  • Überprüfen, ob ein Account überhaupt existiert,
  • Allgemein Benutzerinformationen anhand des Login-Namens feststellen (Vorname, Nachname, Email-Adresse, Telefonnummer...),
  • Autorisierung: Welche Rechte hat dieser Benutzer innerhalb der Applikation,
  • Authentifizierung des Benutzers.

Will man eine flexible, modulare Web-Anwendung entwickeln oder einsetzen, so ist an dieser Stelle darauf zu achten, dass ein Benutzer- oder Anmelde-Plug-in, nicht zwingend all diese Schritte abbilden muss. Ein existierendes LDAP-Plug-in bildet die Schritte Account, Benutzerinfo, Autorisierung gegebenenfalls schon perfekt ab.

Ein Anmelde-Plug-in, das die Web-Applikation um eine Zwei-Faktor-Anmeldung erweitert, sollte also nicht zwingend diese drei bereits sehr gut implementierten Schritte erneut implementieren müssen. Das Anmelde-Framework bzw. der Anmeldestack der Web-Applikation muss also sicherstellen, dass diese verschiedenen Schritte auch unabhängig voneinander implementiert und konfiguriert werden können.

Gute Beispiele: PAM und FreeRADIUS

Die oben aufgeführten Gedanken und Konzepte sind nicht neu. Die bekanntesten Vertreter, die dies umsetzen sind PAM (Pluggable Authentication Modules) und FreeRADIUS.

PAM ist der Anmelde-Stack, der sich in den meisten „unixoiden“ Betriebsystemen durchgesetzt hat. Es unterscheidet mit den Modultypen eben genau diese unterschiedlichen Zuständigkeitsbereiche. So gibt es den Modultyp „account“, der feststellt, ob ein Benutzer existiert, bzw. prinzipiell berechtigt ist, eine Applikation zu benutzen. Der Modultyp „auth“ authentifiziert dann diesen Benutzer. In den PAM-Konfigurationen können für eine Applikation für die verschiedenen Bereiche auch unterschiedliche Module konfiguriert und flexibel kombiniert werden. So muss der Bereich „account“ nicht notwendigerweise geändert werden, wenn man lediglich die Authentifizierung (Bereich „auth“) um einen zweiten Faktor erweitern möchte.

FreeRADIUS legt ebenfalls eine unbegrenzte Flexibilität an den Tag, um den Benutzer zu authentifizieren und dessen Berechtigung zu überprüfen. Dieser Ansatz kennt neben vielen anderen die Bereiche „authorize“ und „authenticate“, die grob den Bereichen „account“ und „auth“ in PAM entsprechen. Auch der FreeRADIUS Server kann in der Sektion „authorize“ unterschiedliche und auch mehrere Module einbinden, um zu überprüfen, ob ein Benutzer überhaupt berechtigt ist, sich hier und auf diese Art und Weise anzumelden. Wenn dies positiv beantwortet wird, wird die Sektion „authenticate“ abgearbeitet und die Anmeldeinformationen (Login Credentials) können auf vielfältige und unterschiedliche Art und Weise – auch abhängig vom Bereich „authorize“ – überprüft werden.

Der jeweils springende Punkt bei PAM und FreeRADIUS ist, dass die Berechtigungen und die Authentifizierung unabhängig voneinander betrachtet werden. Entwickler von Authentifizierungsmodulen können sich rein auf die Authentifizierung konzentrieren und müssen sich nicht zwingend um Benutzer-Accounts oder LDAP-Anbindungen kümmern.

Dies vermeidet Code-Duplizierung und ermöglicht somit schlankeren Code. Weniger Code enthält weniger Fehler, so dass hier von robusteren Modulen ausgegangen werden kann. Ein Modul zu schreiben, dass sich nur um einen Teilbereich und nicht um das komplette Benutzerhandling kümmern muss, ist weniger aufwändig. Dadurch wird es für Drittanbieter attraktiver, für solch einen Anmelde-Stack ein schlankes Modul zu verfassen. Es ist kein unrealistisches Ziel, dass innerhalb dieses Stacks ein individuelles Authentifizierungsmodul in weniger als 60 Zeilen Code verfasst werden können sollte.

Fazit

Jede Web-Applikation die entwickelt wird, sollte diese Gedanken im Hinterkopf behalten und eine entsprechende, leichte Erweiterbarkeit des Anmeldevorgangs erlauben. Existierende Web-Applikationen sollten – bevor sie eingesetzt werden – auf diese Flexibilität hin überprüft werden. Dies muss, um die Zukunftssicherheit zu gewährleisten, ein Entscheidungskriterium bei der Auswahl der entsprechenden Web-Applikation sein.

* Cornelius Kölbel war in den Bereichen Verschlüsselung und starke Authentisierung viele Jahre als Berater tätig und implementierte Lösungen auf Basis marktüblicher Produkte. Bereits seit 1994 beschäftigt er sich mit Open-Source-Projekten, nach 2010 war er Produktmanager eines quelloffenen Zwei-Faktor-Produkts. 2014 rief er das Open-Source Projekt „privacyIDEA“ ins Leben und gründete die NetKnights GmbH.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44251704 / Authentifizierung)