Was passiert, wenn der SSO-Server nicht mehr validiert
Wenn man in der wohlverdienten Kreativ-Pause ist und man eine Email bekommt, dass sich zwei Benutzer in einem System nicht mehr einloggen können, macht einen das stutzig. Mit der Bitte um Überprüfung der Anmelde-Art im joBase-System und der Aactive-Directory-Kontenzuordnung war der erste Verdacht ein Tippfehler oder eine falsche Anmeldeart.
Aus Sicherheitsgründen stand mir in der Ferne die virtuelle Maschine zum Einloggen mit entsprechender 2-Faktor-Authentifizierung für den VPN-Tunnel, sowie den Schlüsselparen für den Zugriff auf die AWS-Instanzen nicht zur Verfügung. Also bliebt nichts weiter außer Ferndiagnose.
Nach der ersten Rückmeldung wurden Tipp- und Konfigurations-Fehler ausgeschlossen, es kam allerdings der Hinweis, dass noch mehr Leute sich nicht einloggen können. Mmh. Das macht einen stutzig - besonders, wenn einer davon ein Administrator ist. Glücklicherweise erreichte mich diese Meldung zum Ende meines Urlaubs.
Zwei Tage später konnte ich mich aufschalten und feststellen, dass mein Login noch funktionierte. Ich prüfte die Einstellungen, alles war OK. Einmal ausloggen, einmal einloggen und... nichts ging mehr. Eine weiße Seite, allerdings nicht vom Applikations-System sonder vom SSO-Server. SSO oder "Single Sign On" bezeichnet eine zentrale Anmelde-Art an Systemen. Es gibt eine Kennung, mit der man sich überall anmelden kann. In diesem Fall gab es sogar einen zentralen Server, der das Login übernimmt und der Applikation mitteilte, welcher Benutzer gerade aktiv ist. Dies tat der zentrale Server-Dienst allerdings nicht mehr. Warum, das wird gerade erforscht. Ich vermute eine deaktivierte Vertrauensstellung für den Applikationsserver. Fakt ist: Es können einige Leute sich gerade nicht mehr einloggen. Wir hoffen auf die Kollegen vom SSO-System. Thats live...
Nun sind einige Tage vergangen und um es vorweg zu nehmen, alle Kollegen können wieder arbeiten. Wie schön.
Nun zum Dilemma. Es kam alles auf einmal. Die SSO-Server wurden vor kurzdem abgeschaltet, da es es seit einigen Jahren bereits Alternativen gab. Im Konzernchaos drang dies jedoch nicht bis zu den Kollegen vor Ort und mir dem Entwickler vor. Die Einrichtung der neuen Vertrauensstellen funktionierte jedoch nicht, da die OIDC-Client-ID gelöscht wurde. Diese ist beim Kunden immer einem Mitarbeiter zugeordnet. Und diesen gab es nicht mehr. Also funktionierte die Umstellung auf die neuen Server natürlich nicht und es war die berühmte Nadel im Heuhaufen suchen.
Wenn man man nun alle technischen Hürden auf Server-Seite genommen hat, muss lediglich ein wenig die Login-Klasse auf das neue Setup angepasst werden und schon erfreuen sich wieder über 45 Benutzer wieder arbeiten zu können.
Spannend ist, wie wir zukünftig mit Änderungen an Server-Infrastruktur umgehen, da die Informationsquellen und Änderungen beim Kunden nicht immer bekannt sind. Zumindest bringt es einen gewissen Nervenkitzel, wenn man als Feuerwehrmann immer entsprechende Notfälle behandeln muss, da es schlicht an der Informationsflut und wenig guter Dokumentation hadert.