Meine Kernkompetenz ist das Mainframe-Betriebssystem IBM z/OS. Dazu gehört für mich auch die Frage, wie sich bestehende Anwendungen mit modernen Anmeldeverfahren verbinden lassen. Bei Abraxas war ich massgeblich an den Tests und der Umsetzung von OpenID Connect beteiligt. Zwei technische Themen sind mir besonders in Erinnerung geblieben: die TLS-Verbindung zum Identity Provider und die Audience im JSON Web Token.
Der öffentliche Hintergrund des Projekts
IBM beschreibt in einer Fallstudie über Abraxas die Modernisierung der Anmeldung mit IBM Z Multi-Factor Authentication und die Einbindung bestehender Identitätsverwaltung. In der Veröffentlichung von Januar 2024 werde ich persönlich zitiert. Die Fallstudie behandelt den gemeinsamen Projektkontext; OpenID Connect wird darin nicht ausdrücklich genannt. Diesen technischen Teil ergänze ich hier aus meiner eigenen Erfahrung.
Die TLS Verbindung zum Identity Provider
Die grösste Herausforderung bei unseren Tests war die Kommunikation zum Identity Provider, von dem das JSON Web Token bezogen wurde. In der AT-TLS-Konfiguration auf z/OS mussten wir dabei insbesondere SNI und den Middlebox Compatibility Mode berücksichtigen, damit die TLS-Kommunikation wie vorgesehen funktionierte.
SNI steht für Server Name Indication. Dabei übermittelt der Client bereits beim TLS-Verbindungsaufbau den gewünschten Servernamen. Das ermöglicht der Gegenstelle beispielsweise, bei mehreren Namen auf derselben IP-Adresse das passende Zertifikat auszuwählen. IBM dokumentiert die zugehörigen AT-TLS-Einstellungen in den TTLSConnectionAdvancedParms.
Der zweite Begriff war MiddleBoxCompatMode. Diese AT-TLS-Option betrifft den TLS-1.3-Handshake: Sie ermöglicht einen kompatiblen Nachrichtenablauf für zwischengeschaltete Systeme, die mit dem reinen TLS-1.3-Handshake Schwierigkeiten haben können. IBM erklärt den Hintergrund in der Dokumentation zur TLS-1.3-Unterstützung. Welche konkreten Parameterwerte wir damals verwendeten, gebe ich hier ohne die ursprüngliche Konfiguration nicht wieder.
Das ist für mich ein wichtiger Punkt bei der Integration: Der Anmeldeweg muss über die beteiligten Systeme hinweg betrachtet werden. Wenn die Kommunikation zum Identity Provider nicht wie vorgesehen funktioniert, reicht die Fehlersuche allein in der Anwendung nicht aus. Auch der Transportweg gehört zur Untersuchung.
Dabei sind die Verbindung zum Identity Provider und die anschliessende Prüfung des Tokens zwei unterschiedliche Aufgaben. Eine funktionierende Verbindung beantwortet noch nicht, ob der Empfänger den Inhalt des Tokens akzeptieren kann.
Zwei Audience Einträge im Token
Ein zweiter Stolperstein war die Audience. Das JSON Web Token enthielt bei uns zwei Audience-Einträge. Nach meiner Erinnerung musste IBM die Verarbeitung dafür anpassen, weil diese Form laut Spezifikation zulässig war.
Die Audience beschreibt, für welche Empfänger ein Token bestimmt ist. Mehrere Werte sind nicht automatisch ein Fehler: Der JWT-Standard RFC 7519 erlaubt für das Feld aud ein Array von Zeichenketten. Bei nur einem Empfänger ist auch eine einzelne Zeichenkette vorgesehen. Entscheidend ist, ob der prüfende Empfänger zu den vorgesehenen Empfängern gehört und die für ihn geltenden Validierungsregeln erfüllt sind.
Für ID Tokens konkretisiert die OpenID-Connect-Spezifikation die Prüfung anhand der registrierten Client-ID und der vertrauten Audiences. Diese Regeln für ID Tokens darf man nicht ungeprüft auf jeden anderen Token-Typ übertragen.
Meine praktische Erfahrung daraus: Beim Testen reicht es nicht, nur festzustellen, dass ein Token vorhanden ist. Man muss seine tatsächliche Struktur und die Erwartungen der beteiligten Komponenten vergleichen. Eine Audience mit zwei Einträgen verdient dabei genauso Aufmerksamkeit wie der sichere Transport.
Was ich aus der Umsetzung mitgenommen habe
Mainframe-Sicherheit verbindet Betriebssystemwissen mit dem Verständnis angrenzender Systeme. Bei OpenID Connect treffen z/OS, Identitätsverwaltung, TLS-Kommunikation und Tokenprüfung aufeinander. Die Tests müssen diese Übergänge mit abdecken.
Mein Beitrag lag in den Tests und der Umsetzung innerhalb des gemeinsamen Projekts. Die beiden beschriebenen Herausforderungen zeigen, weshalb diese Arbeit mehr umfasst als das Einschalten einer neuen Anmeldemethode. Für mich ist das eine konkrete Verbindung zwischen meiner z/OS-Erfahrung und meinem heutigen Schwerpunkt auf Security und IBM zSecure.
Die IBM-Fallstudie bietet den öffentlichen Blick auf das Projekt. Mein Beitrag hier ergänzt die technische Perspektive, ohne interne Konfigurationswerte oder echte Tokens offenzulegen.