ADMIN

2020

12

2020-11-29T12:00:00

Applikationsmanagement

PRAXIS

052

Security-Tipp

Sicherheit

Authentifizierung

FIDO2-Informationen im LDAP hinterlegen

Zugang gewährt

von Matthias Wübbeling

Veröffentlicht in Ausgabe 12/2020 - PRAXIS

In den letzten Monaten stand FIDO2 und die damit verbundene passwortlose Authentifikation immer wieder im Fokus. Solange Sie Ihren Login auf Basis eines flexiblen Datenbanksystems durchführen, können Sie die benötigten Felder für einen oder mehrere öffentliche Schlüssel einfach hinzufügen. Um auch in einem LDAP die notwendigen Informationen zu hinterlegen, müssen Sie das Schema erweitern und eigene Objekt- und Attributtypen definieren. Der Security-Tipp in diesem Monat zeigt, wie Sie dabei vorgehen.

FIDO2 ist ein Meilenstein der passwortlosen Authentifizierung. Beim Login erhält der Browser des Benutzers eine Challenge und muss diese mit dem privaten Schlüssel signieren, sodass der Dienstanbieter die Signatur mit den hinterlegten öffentlichen Schlüsseln verifizieren kann. Ist die Überprüfung erfolgreich, gilt der Login als abgeschlossen.
Ein Vorteil von Public-Key-Verfahren wie FIDO2 liegt darin, dass Dienstanbieter und Benutzer kein gemeinsames Geheimnis (Shared Secret) mehr teilen müssen. Das beinhaltet auch solche Geheimnisse, die etwa für die Zwei-Faktor-Authentifikation zum Einsatz kommen. Somit können diese Geheimnisse auch auf keiner Seite mehr abhandenkommen – Kriminelle erhalten im Zweifel lediglich den öffentlichen Schlüssel eines Benutzers. Dieser darf, wie der Name schon sagt, durchaus öffentlich bekannt sein. Eine Anmeldung bei dem Dienst selbst oder bei anderen Diensten, bei denen der Benutzer denselben Schlüssel hinterlegt hat, bleibt unmöglich. Damit ein Benutzer bei Verlust eines privaten Schlüssels nicht ohne einen Zugang bleibt, lassen sich bei den meisten FIDO2-Implementierungen direkt mehrere öffentliche Schlüssel beziehungsweise unterschiedliche Sicherheitstoken hinterlegen.
LDAP-Schema erweitern
Die im Normalfall verfügbaren LDAP-Schemata, etwa aus der OpenLDAP-Distribution, bieten keine geeigneten Objekte, um die notwendigen Informationen für FIDO2-Authentifikation direkt innerhalb des Verzeichnisses zu speichern. Wie andere Datenbanksysteme erlaubt auch LDAP die Erweiterung speicherbarer Objekte durch das Hinzufügen eines entsprechenden Schemas. Haben Sie ein Schema erfolgreich geladen, können Sie direkt im Anschluss entsprechende Objekte anlegen. Um Verwechslungen vorzubeugen, erhält jedes Schema eine individuelle Identifikationsnummer. Dafür haben sich die weltweit eindeutigen "Object Identifier" (OIDs) etabliert.
FIDO2 ist ein Meilenstein der passwortlosen Authentifizierung. Beim Login erhält der Browser des Benutzers eine Challenge und muss diese mit dem privaten Schlüssel signieren, sodass der Dienstanbieter die Signatur mit den hinterlegten öffentlichen Schlüsseln verifizieren kann. Ist die Überprüfung erfolgreich, gilt der Login als abgeschlossen.
Ein Vorteil von Public-Key-Verfahren wie FIDO2 liegt darin, dass Dienstanbieter und Benutzer kein gemeinsames Geheimnis (Shared Secret) mehr teilen müssen. Das beinhaltet auch solche Geheimnisse, die etwa für die Zwei-Faktor-Authentifikation zum Einsatz kommen. Somit können diese Geheimnisse auch auf keiner Seite mehr abhandenkommen – Kriminelle erhalten im Zweifel lediglich den öffentlichen Schlüssel eines Benutzers. Dieser darf, wie der Name schon sagt, durchaus öffentlich bekannt sein. Eine Anmeldung bei dem Dienst selbst oder bei anderen Diensten, bei denen der Benutzer denselben Schlüssel hinterlegt hat, bleibt unmöglich. Damit ein Benutzer bei Verlust eines privaten Schlüssels nicht ohne einen Zugang bleibt, lassen sich bei den meisten FIDO2-Implementierungen direkt mehrere öffentliche Schlüssel beziehungsweise unterschiedliche Sicherheitstoken hinterlegen.
LDAP-Schema erweitern
Die im Normalfall verfügbaren LDAP-Schemata, etwa aus der OpenLDAP-Distribution, bieten keine geeigneten Objekte, um die notwendigen Informationen für FIDO2-Authentifikation direkt innerhalb des Verzeichnisses zu speichern. Wie andere Datenbanksysteme erlaubt auch LDAP die Erweiterung speicherbarer Objekte durch das Hinzufügen eines entsprechenden Schemas. Haben Sie ein Schema erfolgreich geladen, können Sie direkt im Anschluss entsprechende Objekte anlegen. Um Verwechslungen vorzubeugen, erhält jedes Schema eine individuelle Identifikationsnummer. Dafür haben sich die weltweit eindeutigen "Object Identifier" (OIDs) etabliert.
OIDs kennen Sie vermutlich, wenn Sie schon einmal mit SNMP gearbeitet haben. Dort kommen diese nämlich intensiv für Anfragen und Antworten des Netzwerkmanagement-Protokolls zum Einsatz. Aber auch an anderer Stelle gibt es OIDs, etwa bei der technischen Standardisierung oder in RFCs. Insbesondere die in solchen Dokumenten oft verwendete Syntaxnotation ASN.1 nutzt ebenfalls OIDs. Um nun also eigene Objekte und Attribute in einem LDAP-Schema zu definieren, können Sie bei der IANA einen persönlichen OID-Bereich beantragen [1]. Die Zuteilung eines Teilbaums für Ihre eigenen OIDs gestaltet sich sehr komfortabel und ist innerhalb weniger Tage erledigt.
Für das FIDO2-Schema aus diesem Security-Tipp haben wir bereits OIDs aus dem zugewiesenen Namensraum des Autors vergeben. Diese können Sie natürlich verwenden, solange Sie das Schema nicht noch einmal anpassen müssen. Nur so bleibt die globale Eindeutigkeit gewährleistet.
Aufbau des FIDO2-Schemas
Um FIDO2 in einem LDAP-Verzeichnis abzubilden, benötigen wir unterschiedliche Objekte und Attribute. Zunächst definieren Sie, wie im nachfolgenden Listing dargestellt, den öffentlichen Schlüssel als Attribut:
attributetype ( 1.3.6.1.4.1.56227.1.1.1.1
NAME 'fido2pubkey'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.5
SINGLE-VALUE )
Die OID in der ersten Zeile ist die eindeutige ID dieses Attributtyps. Der Name des Attributs ist frei wählbar, in diesem Szenario führen wir zur einfachen Erkennung das Präfix "fido2" vor allen vergebenen Namen. Die Syntax-Angabe spezifiziert die Art der Daten, die in diesem Objekt gespeichert werden. Der angegebene Wert stammt aus dem Namensraum von Mark Wahl [2], einem der Autoren des LDAPv3-Standards, und gibt an, dass in diesem Attribut Binärdaten gespeichert sind. Die Angabe von "SINGLE-VALUE" bedeutet, dass dieses Attribut nur einmal in dem übergeordneten Objekt enthalten sein darf.
Das "SINGLE-VALUE" verwenden Sie in der Definition, die Sie im nächsten Listing finden. Dort definieren wir den Bezeichner des öffentlichen Schlüssels, den insbesondere die Sicherheitstoken bei der Auswahl des privaten Schlüssels verwenden. Dieser Bezeichner identifiziert also das gesamte Schlüsselpaar. Die angegebene Syntax-OID definiert eine sogenannte IA5-Zeichenkette, einen ASCII-kompatiblen Zeichensatz, wie von der FIDO2-Spezifikation gefordert. Auch dieses Attribut soll nur einmal in dem übergeordneten Objekt enthalten sein:
attributetype ( 1.3.6.1.4.1.56227.1.1.1.2
NAME 'fido2credentialId'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-VALUE )
Nun kombinieren wir den öffentlichen Schlüssel mit dem Bezeichner im resultierenden Objekttyp. Das nächste Listing definiert dieses Objekt für die FIDO2-Authentifikation. Die Informationen der ersten und zweiten Zeile können Sie bereits zuordnen. In der dritten Zeile gibt "SUP top" einen übergeordneten Objekttyp im Sinne einer Vererbungshierarchie an. Als "STRUCTURAL" sind Objekte definiert, die aus anderen Objekt- und Attributtypen kombiniert werden. Dabei definieren die Angaben von MUST und MAY in den nachfolgenden Zeilen die notwendigen und optionalen Attribute unseres Objekts. Das fertige Objekt "fido2credential" besteht also zwingend aus den beiden zuvor definierten Attributen "fido2credentialId" und "fido2pubkey":
objectclass ( 1.3.6.1.4.1.56227.1.1.1.4
NAME 'fido2credential'
SUP top STRUCTURAL
MUST ( fido2credentialId $ fido2pubkey)
MAY ( fido2credentialDescription ))
Optional ist noch ein Attribut des Typs "fido2credentialDescription" angegeben. Das im nachfolgenden Listing definierte Attribut lässt sich etwa dafür verwenden, um die unterschiedlichen öffentlichen Schlüssel zu unterscheiden. Das ist praktisch für die Verwaltung unterschiedlicher Schlüsselpaare durch den Benutzer selbst. Dieser kann die Namen frei wählen und darüber etwa verlorene oder nicht mehr verwendete Schlüsselpaare einfach aus seinem Konto entfernen:
attributetype ( 1.3.6.1.4.1.56227.1.1.1.3
NAME 'fido2credentialDescription'
EQUALITY caseExactMatch
ORDERING caseExactOrderingMatch
SUBSTR caseExactSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
Die Schema-Attribute "EQUALITY", "ORDERING" und "SUBSTR" beschreiben Regeln zur Suche, zum Vergleich und der Sortierung der Werte dieses Typs. Dabei möchten wir in diesem Beispiel groß- und kleingeschriebene Beschreibungen unterscheiden. Die angegebene Syntax "OID" definiert eine UTF-8 kodierte Zeichenkette.
Um die hier entwickelten Typen zu verwenden, fassen Sie diese in einer Schema-Datei zusammen und importieren sie mit ldapadd in Ihren LDAP-Server. Anschließend können Sie Ihren Benutzern Objekte vom Typ "fido2credential" zuweisen. Denken Sie daran, die Zugriffsrechte Ihres LDAP-Servers anzupassen. Insbesondere sollten Sie sicherstellen, dass ein Benutzer die eigenen öffentlichen Schlüssel nur selbst schreiben kann, während der Lesezugriff darauf weniger restriktiv sein darf und je nach Implementierung des Login-Prozesses sogar sein muss.
Fazit
FIDO2 ermöglicht Benutzern passwortlose und sichere Logins in ihre Accounts. Verwenden Sie in Ihrer Umgebung LDAP für die Authentifizierung und möchten FIDO2 einsetzen, können Sie mit dem in diesem Security-Tipp erstellten Schema die notwendigen Objekte und Attribute der FIDO2-Authentifikation in Ihrem Verzeichnis anlegen. Benötigen Sie weitere Elemente in Ihrem Schema, beantragen Sie einen eigenen Bereich im OID-Baum der IANA und erzeugen dort weitere eindeutige Objekt-IDs.
(dr)
Link-Codes
[1] OID-Bereich beantragen: http://pen.iana.org/pen/PenApplication.page/
[2] Namensraum von Mark Wahl: https://www.alvestrand.no/objectid/1.3.6.1.4.1.1466.115.121.1.html/