privacyIDEA Workshop – Teil 6 Mehr-Faktor-Authentifizierung mit Shibboleth und privacyIDEA

Anbieter zum Thema

NetKnights GmbH

cidaas by Widas ID GmbH

Single Sign-on erspart die Passwortflut, macht ein einziges Passwort aber zum Generalschlüssel für alle Dienste. Im sechsten Teil des privacyIDEA-Workshops rüstet die Open-Source-Lösung beim Hochschul-SSO Shibboleth per Plugin den zweiten Faktor nach. Doch wie klappt der Login, wenn jeder einen anderen Faktor mitbringt?

privacyIDEA ist das etablierte Open Source System für Multi-Faktor-Authentifizierung. In den vorherigen Teilen unseres Workshops haben wir ein privacyIDEA-System installiert und einen TOTP-Token ausgerollt, sowie die Richtlinien in privacyIDEA angesehen. Wir haben exem­pla­risch mit FreeRADIUS ein VPN-System angebunden und ein Keycloak für Single Sign-On an Webseiten. Außerdem haben wir gezeigt, wie Admins die Anmeldung an jedem Windows-Desktop per FIDO2, TOTP oder offline, mit dem privacyIDEA Credential Provider absichern.

privacyIDEA Workshop – Teil 1

So geht Mehr-Faktor-Authentifizierung mit Open Source

In Teil 6 des privacyIDEA-Workshop betrachten wir das Single-Sign-on-System Shibboleth. Die Entwicklung von Shibboleth geht bis in das Jahr 2000 zurück, noch bevor das SSO-Protokoll SAML spezifiziert war. Gerade an Hochschulen gab es die Notwendigkeit nicht nur für Single Sign-on, sondern auch für föderierte Anmeldungen. Die Entwicklung von Shibboleth ist eng mit Hochschulen und Universitäten verbunden und es kommt somit auch vor allem bei Hochschulen und im universitären und Forschungsumfeld zum Einsatz.

privacyIDEA verfolgt seit jeher einen modularen Ansatz – unabhängig vom Authentifizierungs­protokoll. Daher implementiert privacyIDEA keinen eigenen SSO Identity Provider, sondern bietet für alle gängigen IdPs entsprechende Plugins an. So auch für Shibboleth. Der Vorteil liegt auf der Hand. Die zweiten Faktoren werden zentral in privacyIDEA verwaltet und Benutzer können ein und denselben zweiten Faktor an allen angeschlossenen Systemen – VPN, Windows-Login, SSO IdP, SSH-Login, u. v. m. – nutzen.

Im Folgenden gehen wir davon aus, dass im Netzwerk bereits eine Shibboleth-Installation vorhanden ist, die derzeit eine einfache Passwort-Authentifizierung macht und mit Hilfe des privacyIDEA-Shibboleth-Plugins um einen zweiten Faktor erweitert werden soll. Wir haben bei den Codezeilen nur die Dinge erklärt, die für genau diesen Schritt relevant sind, damit wir uns nicht in Details verlieren. Wenn es bei der Umsetzung klemmt findet sich im privacyIDEA Community-Forum Hilfe.

privacyIDEA Workshop – Teil 2

VPN an privacyIDEA anbinden

privacyIDEA-Shibboleth-Plugin installieren

Wie alle Komponenten von privacyIDEA wird auch das Shibboleth-Plugin von der NetKnights GmbH transparent bei Github entwickelt. Dort können auch alle Releases heruntergeladen werden. Die aktuellen Releases des Plugins setzen Shibboleth >= 5.0 voraus.

Die Installation des privacyIDEA-Shibboleth-Plugins führen wir als root-Benutzer durch. Beim Schreiben dieses Artikels ist die aktuelle Version des Plugins 1.3.0. Wir laden das Plugin und die aktuelle Signatur-Datei herunter.

Wir aktivieren die MFA-Funktionalität in Shibboleth:

und prüfen dann die aktivierten Module:

Nun installieren wir das privacyIDEA Plugin, das wir zu Beginn heruntergeladen haben.

Zum Schluss können wir prüfen, dass das Plugin korrekt installiert ist:

privacyIDEA Workshop – Teil 3

privacyIDEA mit Policies präzise steuern

Hintergründe zur Kommunikation mit privacyIDEA

Bevor wir das System konkret konfigurieren, wollen wir die Funktionsweise und die daraus entstehenden Möglichkeiten betrachten.

Challenge Response in privacyIDEA

Das privacyIDEA-Shibboleth-Plugin kommuniziert mit dem privacyIDEA Server über die REST API des Servers. Die API unterstützt mehrstufige Challenge-Response-Authentifizierung. D. h. während eines Authentifizierungsvorgangs kann der privacyIDEA Server immer weiterfüh­ren­de Informationen von einem Plugin, bzw. vom Benutzer anfordern.

Das einfachste Beispiel ist die Anmeldung mit einem SMS-Token oder einer E-Mail. Der Benutzer startet die Authentifizierung mit Eingabe von bspw. Benutzername und Passwort, wenn dies richtig ist, antwortet der Server mit der Aufforderung (Challenge), den Wert aus der gesendeten SMS einzugeben. Der privacyIDEA Server kann auf jede Antwort aber auch wieder eine neue Challenge senden. Hierüber können innerhalb des Authentication Flows auch noch weitere Szenarien konfiguriert werden wie das Ausrollen eines Tokens während der Authentifi­zierung oder das Zurücksetzen einer Token-PIN. Gesteuert wird dieses Verhalten immer über den privacyIDEA Server.

Authentication Flows und Konfiguration

Wie das privacyIDEA-Shibboleth-Plugin nun den Authentifizierungsvorgang beginnt, definieren wir in der Konfigurationsdatei „conf/authn/privacyidea.properties“. Der Eintrag „privacyidea.authentication_flow“ akzeptiert die Werte „default“, „triggerChallenge“ oder „sendStaticPass“.

Welchen Flow wir wählen, hängt auch stark davon ab, wo ggf. ein statisches Passwort verifiziert wird und welche Tokentypen zum Einsatz kommen sollen. PrivacyIDEA – und damit auch das privacyIDEA-Shibboleth-Plugin – unterstützt ca. 30 verschiedene Tokentypen. Darunter klassische (T)OTP Token in Software oder Hardware, SMS, E-Mail, PUSH Notification auf das Smartphone, YuibKeys, Passkeys ...

• „default“: Das privacyIDEA-Shibboleth-Plugin wird den Benutzer mit einer Eingabe-Aufforderung begrüßen. Dies ist sinnvoll, wenn vorwiegend TOTP-Token zum Einsatz kommen sollen oder sich das privacyIDEA Plugin auch noch zusätzlich um die Prüfung des statischen Passwortes kümmern soll. Hieraus kann dann natürlich auch ein Challenge-Response-Flow entstehen.

• „triggerChallenge“: In dieser Einstellung sendet ein Service Account einen Request an den privacyIDEA Server, der direkt einen Challenge-Response Flow startet. Das kann bei der Verwendung von PUSH-Token, Passkeys oder SMS sinnvoll sein, wenn das privacyIDEA Plugin nicht das statische Passwort des Benutzers überprüfen soll.

• „sendStaticPass“: Diese Einstellung wird gewählt, wenn man einen Challenge-Response-Flow starten möchte, dafür auf dem Shibboleth Server aber keinen Service Account angeben will. In diesem Fall sendet das privacyIDEA-Shibboleth-Plugin initial einen Authentifizierungs-Request mit einem statischen Passwort an den privacyIDEA Server. Je nach Konfiguration des Servers kann dies dann einen Challenge-Response-Flow auslösen oder für manche Benutzer sogar dazu führen, dass das Plugin gar nicht nach einem zweiten Faktor fragt. Das kann sinnvoll sein, wenn man ein gemischtes Szenario aus Benutzern mit zweitem Faktor und Benutzer ohne zweiten Faktor hat.

privacyIDEA Workshop – Teil 4

Keycloak an privacyIDEA anbinden

Einbindung des privacyIDEA Plugins

Wie genau die Übergänge im Shibboleth-MFA-Flow sind, kann der Administrator in der Datei „conf/authn/mfa-authn-config.xml“ festlegen. Es gibt hier verschiedene Möglichkeiten, das privacyIDEA Plugin einzubinden. Wenn privacyIDEA bspw. die komplette Authentifizierung übernimmt, dann sind auch Szenarien mit Passkey (passwordless / usernameless) möglich. Bei Github finden sich Beispiele, wie das privacyIDEA Plugin in den Flow eingebunden werden kann.

Konfiguration der Anbindung an privacyIDEA

Starten wir jetzt in unsere Konfiguration. Dazu müssen wir lediglich die drei Dateien „conf/authn/auth.properties“, „conf/authn/mfa-authn-config.xml“ und „conf/authn/privacyidea.properties“ editieren.

auth.properties

Wir aktivieren die MFA-Funktionalität, indem wir in der Datei „conf/authn/auth.properties“ den Shibboleth MFA Flow auswählen:

mfa-authn-config.xml

Wie beschrieben, gibt es verschiedene Arten, das privacyIDEA Plugin einzubinden. Wir entscheiden uns der Einfachheit halber für die Nutzung des bestehenden Passwortes und die zusätzliche Abfrage des zweiten Faktors gegen privacyIDEA. Der entscheidende Abschnitt in der Datei „conf/authn/mfa-authn-config.xml“ sieht dann so aus:

privacyIDEA Workshop – Teil 5

Sichere Anmeldung an jedem Windows-Desktop mit privacyIDEA

Nun müssen wir nur noch das privacyIDEA Plugin selber konfigurieren. Die minimale Konfiguration definieren wir in „conf/authn/privacyidea.properties“ wie folgt:

In diesem Fall lösen wir eine Challenge mit dem angegebenen Service Account aus.

privacyIDEA Server

Auf Seiten des privacyIDEA Servers benötigen wir eine Authentication Policy, so dass der TOTP-Token des Benutzers auch im Challenge Response Mode funktioniert:

• Policy-Scope: auth

• Action: challenge_response=totp

Zusätzlich benötigt der Service Account eine administrative Richtlinie, die ihm die Aktion triggerChallenge erlaubt. Für weitere Infos zu den Admin-Richtlinien und den Auth-Richtlinien sei auf den Teil 3 dieser Workshop-Reihe verwiesen.

Shibboleth mit zweitem Faktor gegen privacyIDEA

Bildergalerie

Wenn sich nun ein Benutzer „cornelius“ gegen Shibboleth authentisiert, so muss er als erstes wie gewohnt sein Passwort eingeben (Siehe Bild 1).

Nachdem dieses von Shibboleth gegen „authn/Password“ verifiziert wurde, wird das privacyIDEA Plugin im Modus „triggerChallenge“ einen Request gegen privacyIDEA senden. Der Benutzer wird dann zur Eingabe seines zweiten Faktors aufgefordert (Siehe Bild 2).

In unserem Beispiel beantwortet der Benutzer diesen einfach mit seinem TOTP-Token. Im Hintergrund hat das privacyIDEA Plugin einen „/auth“ Request gegen den privacyIDEA Server gesendet, um Berechtigung auf die REST API zu erhalten. (Siehe Eintrag 25030 in Bild 3)

Das Plugin löst dann einen „/validate/triggerchallenge“ Request (25031 in Bild 3) für den Benutzer „cornelius“ aus. Im Auditlog sehen wir auch schon, dass sich dieser Challenge auf den TOTP-Token des Benutzers bezieht.

Das ist der Moment, in dem der Benutzer nach dem OTP-Wert gefragt wurde. Gibt der Benutzer nun den OTP-Wert ein, so sendet das Plugin den finalen „/validate/check“ Request (Eintrag 25033 in Bild 3), der mit „ACCEPT“ bestätigt wird und der Benutzer ist angemeldet.

In diesem Workflow können wir genauso und gleichzeitig SMS, E-Mail-Token, PUSH-Notification oder Passkeys verwenden. Benutzer können unterschiedliche Tokentypen nutzen.

Die Konfiguration am Shibboleth bleibt die gleiche und muss nicht angepasst werden. Die verschiedenen Tokentypen für die unterschiedlichen Benutzer können zentral in privacyIDEA verwaltet werden.

Über die Einstellung „privacyidea.authentication_flow“ und die Verknüpfungen in der MFA-Konfiguration „mfa-authn-config.xml“ lassen sich weitere, beliebige Anmeldeszenarien abbilden, bis hin zu einer passwortlosen Anmeldung mittels Passkeys.

privacyIDEA im Einsatz

So funktioniert MFA mit Open Source

Nächste Schritte in der Workshop-Reihe

Der privacyIDEA Server und die dazugehörigen Plugins werden kontinuierlich weiterentwickelt. Dabei ist das Ziel, nicht nur die Verwaltung der Token sondern auch die Konfigurationslogik so weit wie möglich zentral im Server zu halten. In einem folgenden Beitrag wollen wir auf weitere Funktionen des Servers und des Shibboleth-Plugins eingehen, die mit der nächsten Version von privacyIDEA verfügbar sein werden.

Die Security-Insider-Redaktion freut sich über Feedback, welche Themen Sie sich für weitere Folgen dieses Workshops wünschen! Ansonsten finden Sie weitere Infos auf dem Youtube-Kanal von privacyIDEA oder im Community-Forum.

Über den Autor: Cornelius Kölbel beschäftigt sich seit 2004 mit Multifaktor-Authentifizierung. Als Berater lernte er, die Anforderungen der Kunden in heterogenen Netzwerken aus erster Hand zu verstehen. Er plante und implementierte mehrere Public-Key-Infrastrukturen für Smartcard-Nutzung und war einer der ersten der an der Interoperabilität des Aladdin eToken zwischen Windows und Linux gearbeitet hat. 2014 startete Kölbel das Open-Source-Projekt privacyIDEA und gründete die NetKnights GmbH, die Beratung und Support rund um privacyIDEA anbietet. In den letzten Jahren sprach er auf nationalen und internationalen Konferenzen und veröffentlichte zahlreiche Artikel.

(ID:50968879)