Updates

• 19. Dezember 2023

Ich habe an dieser Stelle bereits früher über Möglichkeiten der Nutzung von Einmalpasswörtern entsprechend RFC RFC 6238 in Java-Anwendungen berichtet. Nun wollte ich untersuchen, ob sich 2-Faktor-Authentifizierung in das Framework Java Authentication and Authorization Service (JAAS) integrieren lasen würde.

JAAS ist ein Framework, das es gestattet, Authentifizierung unkompliziert den Gegebenheiten und Anforderungen der jeweiligen Anwendung anzupassen: Die zu nutzenden Module für die eigentliche Authentifizierung werden in einer Konfigurationsdatei spezifiziert und zur Laufzeit instantiiert.

Ich wollte nun basierend auf dem UnixLoginModule und dem com.sun.security.auth.module.NTLoginModule eine 2-Faktor-Authentifizierung realisieren. Prinzipiell müsste aber jedes LoginModule nutzbar sein, sofern es einen Principal in den LoginContext einfügt. Ich wollte dazu über TOTP ein Token erzeugen, das als zweiter Faktor dienen sollte. Dazu erstellte ich zunächst eine Klasse, die ein einfaches Enrollment für HOTP/TOTP erlaubte. Damit erstellte ich für den Testanwender eine Datei in seinem Home-Verzeichnis. Das ist ein ähnliches Verfahren, wie es auch beim Yubikey oder dem originalen Google-Authenticator für die Benutzung mit Linux Pluggable Authentication Modules (PAM) genutzt wird.

Das neu zu erstellende LoginModule liest diese Datei ein - sofern sie nur die Rechte OWNER_READ und OWNER_WRITE gesetzt hat (unter Linux - unter Windows muss dieser Test aus naheliegenden Gründen entfallen)- und sucht das Secret des betreffenden Nutzers. Als Schlüssel dieser Suche wird der Name des durch eines der anderen definierten Module in den LoginContext eingefügten Principal benutzt. Mit diesem Secret wird dann der aktuell gültige Token ermittelt und mit dem, der vom Anwender eingegeben wurde verglichen.

Wichtig hierbei ist, dass das (komfortabel) nur möglich ist, wenn das in der Phase Commit des JAAS-Prozesses erledigt wird - nur dann sind Principals bereits gesetzt und man kann den Namen eines solchen Principal benutzen, um das entsprechende Secret aus der Datei zu lesen - die Alternative wäre, den Namen nochmals abzufragen.

Im Zuge dieses Experiments wurde der gesamte Code zum Thema OTP nochmals großmaßstäblich neu geschrieben. Die entsprechenden Klassen werden ab dem nächsten Update des Artefakts de/elbosso/util zur Verfügung stehen.

Die folgenden Zeilen zeigen eine beispielhafte Konfiguration jaas_2fa.config für eine Anwendung, die unter Linux und Windows gleichermaßen funktionieren soll:

twofa {
    com.sun.security.auth.module.UnixLoginModule optional debug=true;
    com.sun.security.auth.module.NTLoginModule optional debug=true;
    de.elbosso.util.security.TOTPLoginModule required debug=true otpuri=".TOTPTest.uri" principalClass="com.sun.security.auth.UnixPrincipal,com.sun.security.auth.NTUserPrincipal";
};

Der Parameter otpuri beschreibt falls er wie in diesem Beispiel einen relativen Dateinamen darstellt den Ort der Datei mit den Secrets relativ zum Home-Verzeichnis des Nutzers, der die Anwendung ausführt. Ist hier ein absoluter Pfad angegeben, wird dieser benutzt - egal welcher Nutzer die Anwendung ausführt.

Ich habe hier noch einige Links zu diesen Themen zusammengefasst:

Aktualisierung vom 19. Dezember 2023

<repository>
	<id>gitlab</id>
	<name>EL BOSSOs (https://elbosso.github.io/index.html) Maven Repository</name>
	<url>https://elbosso.gitlab.io/mvn/repository/</url>
</repository>

<dependency>
	<groupId>de.elbosso</groupId>
	<artifactId>util</artifactId>
	<version>2.3.0-SNAPSHOT</version>
</dependency>

Links

Kommentar hinzufügen (via ) Kommentare ansehen (via )

Kommentar hinzufügen (via ) Kommentare ansehen (via )