Millionen von Arbeitnehmern starten jeden Morgen ihren Firmen-PC und geben User-Namen sowie Passwort ein. Bevor es mit der Arbeit richtig losgehen kann, müssen sie jedoch häufig eine Reihe weiterer User-IDs und Passwörter eintippen, bis alle notwendigen Applikationen, Datenbanken und Dienste zur Verfügung stehen. Mitarbeiter, die sich diese Vielfalt nicht merken wollen, "verstecken" Kennwortlisten unter ihrer Tastatur. Und darunter leidet die Sicherheit. Andere, die um die Sensibilität interner Sicherheitsfragen wissen, haben spätestens nach einem dreiwöchigen Urlaub das eine oder andere Passwort vergessen und bemühen dann den User-Support.
Viele Anwender träumen deshalb von dem einen Schlüssel, der ihnen die ganze Bandbreite der IT-Dienste und Programme im Unternehmen öffnet. Die- ses "Single-Sign-on"-Verfahren kommt tatsächlich schon in einigen Unternehmen zum Einsatz, allgemeine Praxis ist es allerdings noch lange nicht. Dies lässt sich im Wesentlichen auf zwei Gründe zurückführen: Die Einführung einer solchen Lösung ist technisch keineswegs trivial. Zudem sind die wenigsten Unternehmen bereit, für den so erzielten Komfortgewinn die ohnehin knappen IT-Budgets zu belasten.
Vor genau diesem Problem stand auch das IT-Architektur-Team der Commerzbank. Dort wünschten sich die Anwender, die Login-Vielfalt zu reduzieren. "Wir haben eine heterogene IT-Landschaft, die neben der Windows-Welt unsere Host-basierenden Backend-Systeme sowie zahlreiche Unix- und Java-Komponenten umfasst", verläutert Christiane Vorspel, IT-Architektin bei der Commerzbank. Ihre Abteilung, der Zentrale Servicebereich IT Support Enterprise Architecture, nahm daher die Wünsche der Anwender ernst. Doch musste er feststellen, dass es einfache Lösungen für die Problemstellung nicht gab.
Investitionen ohne jedes Verhältnis zum Nutzen
Dabei waren die Voraussetzungen für eine SSO-Lösung bei der Commerzbank nicht mal schlecht. So verfügte der Finanzdienstleister bereits über ein Meta-Directory, in dem für jeden Nutzer eine User-ID angelegt ist. Außerdem lassen sich dort über ein zentrales Administrations-Tool Ressourcen, Rollen und damit verbundene Zugriffsrechte einzelner Anwender verwalten. Dennoch erfolgt die Nutzer-Authentisierung dezentral bei den verschiedenen Systemen - woraus sich auch die Vielzahl an Passwörtern ergibt.
"Um hier Abhilfe zu schaffen, könnte man eine sehr umfangreiche SSO-Komponente vor das Meta-Directory stellen", beschreibt Vorspel die Herausforderung. Diese müsse nicht nur auf das zentrale Verzeichnis zugreifen, sondern Verzweigungen in alle angeschlossenen IT-Systeme umfassen. Derartige Verbindungen zu etablieren sei jedoch mit einem immensen Aufwand verbunden: "Da gerät man schnell in Investitionsbereiche, die im zweistelligen Millionen-Euro-Bereich liegen - und das steht in keinem Verhältnis zum Nutzen", begründet die IT-Architektin, warum derartige Ansätze für die Commerzbank nicht in Frage kamen.
Anstatt jedoch die Hände in den Schoß zu legen, entschied sich Vorspels Team, mit einer pragmatischen und kostengünstigen Teillösung den Komfort für die Nutzer dennoch deutlich zu erhöhen. Dabei konnte die Architekturexpertin auf die Ergebnisse eines im Jahr 2000 gestarteteten Java-Projekts zurückgreifen. Ihre Abteilung hatte für den unternehmensweiten Java-Einsatz eine Standardarchitektur geschaffen, die gemeinsam mit den verschiedenen IT-Abteilungen der Commerzbank umgesetzt wurde.
Zumindest für alle .NET- und Java-basierenden Anwendungen
"In diesem Rahmen haben wir eine klassische Java Enterprise Architecture hingestellt, die auf dem IBM Websphere Application Server basiert", berichtet Vorspel. Eine Thin-Client-Architektur wurde dabei an die Middleware-, Monitoring- und Security-Systeme der Bank angebunden. Die Host-Anwendungen sind dadurch für die Anwender häufig nicht mehr sichtbar, denn diese greifen über Java- oder Visual-Basic-User-Interfaces darauf zu. Die eigentlichen Transaktionen laufen im Hintergrund und werden über die Middleware angestoßen.
Ausgehend von dieser Basisinfrastruktur machte sich das Team daran, den Komfort der Lösung zu verbessern. Statt eines SSO-Konzepts, das die gesamte Anwendungslandschaft umfasst, implementierte es eine Lösung, die zumindest den Login für sämtliche .NET- und Java-basierenden Anwendungen erleichtert.
Die User können nach dem Windows-Login ohne Eingabe weiterer Passwörter via Browser auf alle Java-basierenden Anwendungen zugreifen. Dabei prüft eine selbst entwickelte Software, ob eine regelkonforme Anmeldung vorliegt und der Anwender die Nutzungsrechte für die jeweilige Applikation hat. Das Programm selbst besteht eigentlich nur aus wenigen Codezeilen.
Die große Herausforderung lag also nicht in der Codierung, sondern in der Absicherung der Lösung. "Wir haben uns sehr intensiv mit unseren Sicherheitsexperten abgestimmt und gemeinsam ein umfassendes Sicherheitskonzept erstellt", erläutert Vorspel. Hier galt es vor allem, den Austausch von Authentisierungsinformationen zwischen den beteiligten Plattformen mittels Verschlüsselung und Signaturen abzusichern.
Für den Anwender ist der Anmeldeprozess transparent
"Wenn ein Anwender über einen Link eine Java-Anwendung aufruft, läuft im Prinzip das gleiche Verfahren ab wie bei der anfänglichen Windows-Anmeldung - nur dass sich dabei die beteiligten Systeme automatisiert miteinander unterhalten", führt Vorspels Kollege Hartwig Gelhausen aus. Über ein Informations-Cookie werden die Anwenderdaten verschickt. Nach der Bestätigung, dass der User in der entsprechenden Domäne angelegt ist, geht ein verschlüsseltes und signiertes Cookie an den Web Application Server, der seinerseits ein Authentifizierungs-Token erstellt und an den Browser schickt. Nach diesem für den Anwender selbst völlig transparenten Prozess kann er auf die entsprechende Java-Anwendung zugreifen.
Tief in die Eingeweide der Verschlüsselungs-Algorithmen
"Das hört sich erstmal einfach an, allerdings lag insbesondere bei der Verschlüsselung der Teufel im Detail", erinnert sich Gelhausen. Daten auf einer .NET-Plattform zu verschlüsseln und sie auf der Java-Seite wieder zu entschlüsseln bereitete den Entwicklern erhebliche Schwierigkeiten. Obwohl dafür Standardverfahren einErkelenz Marienviertelgesetzt wurden, gelang die Entschlüsselung anfangs nicht, was eine aufwändige Fehlersuche zur Folge hatte. Letztendlich lag es an einer Einstellung auf der .NET-Seite, die für das Verfahren geändert werden musste. "Um dies herauszufinden, mussten wir schon sehr tief in die Eingeweide der Verschlüsselungsalgorithmen greifen", so Gelhausen.
Nachdem diese Probleme mit Hilfe des IT-Dienstleisters Prodyna überwunden worden waren, läuft das System den IT-Architekten zufolge performant und sicher. So ließ sich mit der von Vorspel scherzhaft als "SSO für Arme" bezeichneten Lösung ein deutlicher Komfortzuwachs für die Anwender erreichen.
Lediglich Softwarepakete, die eine eigene User-Verwaltung aufweisen, sind damit nicht abgedeckt. Dazu zählen beispielsweise die SAP-Systeme der Bank sowie einige Front-Office-Anwendungen im Bereich Investment-Banking.
Aufgrund dieser Abstriche ließ sich die Lösung ohne größere Investitionen einführen. "Wir sind mit dem Preis-Leistungs-Verhältnis sehr zufrieden", freut sich Vorspel. Das Projekt konnte in neun Monaten von zwei internen und einem externen Mitarbeiter gestemmt werden. In die erforderliche Hardware musste der Finanzdienstleister ebenfalls kaum investieren, da das Team auf bereits vorhandene Ressourcen zurückgreifen konnte.