Legacy-Auth: JAAS Custom Login Module und LTPA

Beispiel: NovarisLegacyLoginModule + LegacyUserDirectory (novaris-policy-web-legacy-jsf).

Bevor SAML/OIDC in Unternehmens-Java-EE-Landschaften Einzug hielten, war die Kombination aus JAAS Custom Login Module (Authentifizierung) und LTPA (Single-Sign-on zwischen WebSphere-Anwendungen) der Standardweg fuer Unternehmensauthentifizierung auf WebSphere. Beide Teile sind konzeptionell getrennt und loesen unterschiedliche Probleme.

Teil 1: JAAS Custom Login Module - "WIE wird geprueft, wer sich anmeldet?"

Siehe NovarisLegacyLoginModule-Javadoc fuer den vollstaendigen Code-Walkthrough. Der Kern: JAAS definiert einen genormten Lebenszyklus (initialize → login → commit/abort), den jeder Login-Provider implementieren kann, ohne dass der Container wissen muss, WIE konkret geprueft wird. Diese Klasse prueft gegen LegacyUserDirectory (in diesem Projekt ein simulierter In-Memory-Speicher) - in einer echten Landschaft waere das haeufig eine LDAP-Bind-Operation oder eine Abfrage gegen ein eigenes Altsystem-Benutzerverzeichnis, das schon lange vor WebSphere existierte und nie durch LDAP abgeloest wurde. Genau das ist der historische Grund, warum es ueberhaupt ein Custom Login Module gibt - die eingebauten WebSphere-Registries (lokale Datei, LDAP) reichen nicht, wenn die "Wahrheit" ueber Benutzer in einem proprietaeren Altsystem liegt.

Wie es an WebSphere angebunden wird (nur dokumentiert, nicht ausfuehrbar)

WebSphere traditional: Admin Console → Security → Global Security → Java Authentication and Authorization Service → Application logins → neuer Eintrag mit der voll-qualifizierten Klasse com.novaris.legacy.web.security.NovarisLegacyLoginModule. WebSphere Liberty: gleichwertig ueber server.xml:

<jaasLoginContextEntry name="NovarisFormLogin">
    <jaasLoginModule className="com.novaris.legacy.web.security.NovarisLegacyLoginModule"
                      controlFlag="required"/>
</jaasLoginContextEntry>

Der realm-name in web.xml (<login-config><realm-name>NovarisFormLogin</realm-name>) verweist auf genau diesen Eintrag - das ist die Bruecke zwischen "wie soll sich der Nutzer anmelden" (Web-Deskriptor) und "wie wird tatsaechlich geprueft" (JAAS-Konfiguration).

Teil 2: LTPA - "WIE bleibt man ueber mehrere Anwendungen hinweg angemeldet?"

LTPA (Lightweight Third Party Authentication) ist ein WebSphere-proprietaeres Single-Sign-on-Verfahren. Nach erfolgreichem Login (Teil 1) stellt WebSphere selbst - nicht die Anwendung, nicht das Login Module - ein signiertes Token aus, das als Cookie (LtpaToken2) an den Browser geht. Jede WebSphere-Anwendung, die dieselben LTPA-Schluessel verwendet (typischerweise alle Anwendungen derselben "Zelle"), akzeptiert dieses Cookie als Nachweis einer bereits erfolgten Anmeldung - der Nutzer meldet sich nur einmal an und bewegt sich danach nahtlos zwischen mehreren WebSphere-Anwendungen, ohne erneut Zugangsdaten einzugeben.

Warum das hier nur dokumentiert, nicht implementiert wird: LTPA-Tokens sind mit WebSphere-internen, proprietaeren Schluesseln signiert - es gibt keine sinnvolle Moeglichkeit, dieses Verhalten ausserhalb einer echten WebSphere-Installation nachzubauen oder zu testen. Das ist eine bewusste, saubere Grenze: alles, was mit Standard-Java-SE-Mitteln (JAAS selbst) funktioniert, ist in diesem Projekt echter, lauffaehiger und getesteter Code (NovarisLegacyLoginModuleTest); alles, was WebSphere-proprietaer ist (LTPA-Ausstellung/ -Validierung), ist Dokumentation.

Praktische Konsequenzen von LTPA, die man kennen sollte

• Schluesselverteilung: Mehrere WebSphere-Zellen/-Cluster koennen LTPA-Schluessel austauschen, um SSO auch ueber Zellgrenzen hinweg zu ermoeglichen - ein haeufiger Konfigurationsschritt bei Konzern-Landschaften mit mehreren WebSphere-Installationen.
• Ablaufzeit: LTPA-Tokens haben eine konfigurierbare Gueltigkeitsdauer (Default oft 120 Minuten) - laeuft sie ab, muss sich der Nutzer erneut anmelden, auch wenn seine HTTP-Session serverseitig noch aktiv waere.
• Migrationsrelevanz: Bei einer spaeteren Modernisierung (siehe "spaeter", nicht Teil dieses Projekts) ist LTPA einer der Punkte, die durch OIDC/SAML ersetzt werden muessen - eine reine "Wir haben denselben Login-Bildschirm" ist ohne LTPA/OIDC-Aequivalent keine vollstaendige Migration, wenn SSO zwischen mehreren Anwendungen erhalten bleiben soll.

Zusammenspiel im Ueberblick

Browser --FORM-POST(j_username,j_password)--> j_security_check (Container-Mechanismus)
                                                     |
                                     JAAS: NovarisLegacyLoginModule.login()/commit()
                                                     |
                                     Subject mit NovarisPrincipal + NovarisRolePrincipal(s)
                                                     |
                              WebSphere stellt LTPA-Token aus (Cookie LtpaToken2)
                                                     |
                     Folgeanfragen (auch an ANDERE WebSphere-Anwendungen derselben Zelle)
                     werden anhand des LTPA-Cookies automatisch authentifiziert - kein
                     erneuter Login-Durchlauf noetig