Teil 3: Elytron Security Subsystem
Das Elytron Security Subsystem gibt es bereits seit EAP 7.1. Allerdings wurde in den EAP 7.x Versionen parallel noch das frühere Security Subsystem unterstützt, das jetzt als Legacy-Subsystem bezeichnet wird. Wir vermuten daher, dass in vielen Organisationen nicht auf Elytron umgestellt wurde.
Was ist mit Legacy Security?
In der Praxis haben wir viele Erfahrungen mit Systemen gesammelt, in denen selbst geschriebene Login-Module eingesetzt werden. Grundsätzlich ist es kein Problem, wenn das Know-How und der Source-Code vorhanden sind, bzw. wenn es Ressourcen für die Migration der Login-Module auf Elytron gibt. Es kann aber immer wieder vorkommen, dass eigene Login-Module auf EAP8 AS-IS weiterverwendet werden müssen. Ist es möglich und wenn ja, wie aufwändig ist es, einen „Adapter“ einzurichten? Wir wollten diese Fragen beantworten und haben ein eigenes Login-Modul für das alte Security-Subsystem implementiert. Im Wesentlichen ist das eine Implementierung des Interfaces javax.security.auth.spi.LoginModule.
Kurze Antwort: Ja, das ist möglich. Wir haben dazu den JAAS-Realm von Elytron verwendet.
Welche Schritte sind dafür nötig?
Zuerst wird die Login-Modul Klasse in ein JBoss-Modul (com.gepardec.training.jboss.loginmodule) gepackt und im modules Verzeichnis abgelegt. Die Konfiguration des Login-Moduls erfolgt nicht mehr in der standalone.xml, sondern in einer eigenen JAAS Login Configuration Datei. Diese hat folgende Struktur.
<name used by application to refer to this entry> {
<LoginModule> <flag> <LoginModule options>;
<optional additional LoginModules, flags and options>;
};
In unserem Beispiel speichern wir
test {
com.gepardec.training.jboss.loginmodule.SimpleUsersRolesLoginModule required
user1=max password1="max@123" role1=users
user2=moritz password2="moritz@123" role2=friends
;
};
in einer Datei namens JAAS-login-modules.conf im Konfigurationsverzeichnis der JBoss-Instanz. Unser LoginModul kennt nur zwei Benutzer, die direkt in der JAAS Login Configuration konfiguriert werden. Für Produktion ist so ein LoginModul natürlich nicht geeignet.
Zuletzt konfigurieren wir noch den jaas-realm im Elytron Subsystem mittels JBoss-CLI:
set CONFIG_DIR=`:resolve-expression(expression=${jboss.server.config.dir})`
/subsystem=elytron/jaas-realm=myAppsRealm:add(\
entry=test,\
path=$CONFIG_DIR/JAAS-login-modules.config,\
module=com.gepardec.training.jboss.loginmodule)
/subsystem=elytron/security-domain=myapps:add(\
default-realm=myAppsRealm,\
realms=[{realm=myAppsRealm}],\
permission-mapper=default-permission-mapper)
/subsystem=elytron/http-authentication-factory=example-loginconfig-http-auth:add(\
http-server-mechanism-factory="global",\
mechanism-configurations=[{mechanism-name="BASIC",\
mechanism-realm-configurations=[{realm-name="FSRealmUsers"}]}],\
security-domain=myapps)
/subsystem=undertow/application-security-domain=myapps:add(\
security-domain=myapps)
Der Workaround mit CONFIG_DIR ist zugegeben nicht elegant, aber ein Bug WFCORE-6186 verhindert derzeit noch, das bessere relative-to Attribut zu verwenden. Das war’s! Wir haben zuerst unsere Test-Applikation auf EAP 7.4 mit diesem Login-Modul für das Legacy-Security-Subsystem getestet und dann auf EAP 8 mit demselben Login-Modul über JAAS-Realm. Authentifizierung und Autorisierung haben wie erwartet ohne Fehler funktioniert.
Zusammenfassend erscheint uns diese Lösung für Legacy LoginModule durchaus praktikabel. Auch mit umfangreichen Konfigurationsoptionen bleibt die Konfiguration lesbar. Alternativ könnte man die Funktion des LoginModuls neu in einem Security Realm implementieren. Mittel- und langfristig ist das auch empfehlenswert.
