Vereinfachte Prüfung von Zugangsberechtigungen mit IBM’s neuem EIM Feature in Verbindung mit Kerberos

von Patrick Botz

Server-Schnittstellen für Kerberos

Mit V5R2 hat IBM diverse Betriebssystem- und Client-Schnittstellen erweitert, um eine optionale Authentifizierung durch Kerberos zu ermöglichen. Die Schnittstellen wurden angepasst für: den iSeries Navigator, die PC 5250 Emulation, den Client-Teil des in OS/400 zur Verfügung gestellten ODBC-Treibers sowie für die Host Server, den NetServer, QFileSvr400, ODBC, JDBC, die Server innerhalb der DRDA-Architektur (Distributed Relational Database Architecture) und letztlich den Telnet Server auf der Host-Seite.

Der PC5250 Emulator (z.B. der Telnet Emulator, der mit iSeries Access for Windows ausgeliefert wird) lässt sich für die Kerberos Authentifizierung konfigurieren. Das hat zur Folge, dass ein Benutzer beispielsweise nach dem Start der Emulation ohne gesonderte Anmeldung direkt sein Anfangsmenü angezeigt bekommt oder dass sofort sein Startprogramm ausgeführt wird. Das wird möglich, da der Telnet Server auf EIM Informationen zugreift und der Benutzer bereits bei der Anmeldung an seinem System mit dem entsprechenden Benutzerprofil über Kerberos authentifiziert wurde.

Innerhalb des iSeries Navigators können sich Benutzer durch einfachen Mausklick auf einem System anmelden. Sie werden unter ihrem jeweils korrekten Benutzerprofil angemeldet, unabhängig davon, unter welcher Benutzer-ID sie in Windows 2000 angemeldet sind.

Die NetServer Erweiterungen bieten dem Benutzer die Möglichkeit, sich einen in OS/400 freigegebenen Ordner als Laufwerk zuzuordnen, ohne sich dem NetServer gegenüber erneut authentifizieren zu müssen. Aber hierbei besteht eine entscheidende Einschränkung: Der NetServer implementiert das Microsoft Software Message Block (SMB) Protokoll. Dieses Protokoll bedingt, dass wenn auch nur ein einziger PC Zugriff auf den NetServer nimmt, der nicht Windows 2000 oder eine spätere Version installiert hat, eine Authentifizierung über Kerberos nicht mehr zugelassen wird. Auch alle anderen PCs müssen sich dann über User-ID und Passwort gegenüber dem NetServer neu authentifizieren.

QFileSvr400 kann man sich als das OS/400 Äquivalent zum NFS (Network File System) vorstellen. Es erlaubt Benutzern, dem lokalen OS/400 Dateisysteme zuzuordnen, die sich physisch auf einem fernen OS/400 befinden. Auch QFileSvr400 unterstützt nun Kerberos für die Authentifizierung.

Die Erweiterungen in ODBC, JDBC und DRDA SSO ermöglichen Benutzern nun die Ausführung von SQL oder selbst entwickelten ODBC (oder JDBC) Programmen über den iSeries Navigator. Das Interessante daran ist, dass das SQL Programm keine Prompts oder hart codierte User-IDs oder Passworte mehr enthalten muss. Das macht es nun möglich, Anwendungen wirklich multitiered (z.B. PC-zu-iSeries, iSeries-zu-zSeries, iSeries-zu-iSeries) und heterogen (z.B. Windows 2000, OS/400, zOS) zu entwickeln, wobei der einzige zu entwickelnde Code der Windows 2000 Code ist, der eine SQL Anforderung an ein iSeries System übermittelt. Der gesamte Rest bezüglich der notwendigen Authentifizierung wird von den Betriebssystemen mit Hilfe von EIM und Kerberos erledigt.

Durch die SSO- und EIM-Fähigkeiten ergeben sich in einer ganzen Reihe von Szenarien nützliche Auswirkungen. Stellen wir uns beispielshalber ein Unternehmen vor, das einen Benutzer namens Fred beschäftigt. Fred verfügt über ein Windows 2000 Netzwerkprofil mit der Bezeichnung FRED, ein Benutzerprofil auf SYSTEM1 mit der Bezeichnung LARRY mit PASSWORD *NONE und ein drittes Profil auf SYSTEM2 mit der Bezeichnung MOE, ebenfalls mit PASSWORD *NONE. Wenn Fred sich morgens auf seinem Laptop anmeldet, tut er das mit der Benutzer-ID FRED. Ein Verzeichnis des Systems SYSTEM2 („RemDir“), das zwei Streamfiles (MoeAccess und NoMoeAccess) enthält, ist auf SYSTEM1 unter Verwendung von „/other“ als mount point referenziert (mounted).

Nachdem Fred sich als FRED an seinem Laptop angemeldet hat, startet er den iSeries Navigator und klickt auf SYSTEM1. Dort wird er umgehend als LARRY angemeldet, ohne sich neu authentifizieren zu müssen. Nun klickt Fred auf IFS, root und „other“ auf der linken Seite der Anzeige iSeries Access for Windows. LARRY verfügt über die private Berechtigung *USE für das Verzeichnis „/other“ auf SYSTEM1, damit authentifiziert QFileSvr400 ihn nun mittels Kerberos gegenüber SYSTEM2. QFileSvr400 prüft die Authentifizierung und bildet die Kerberos Identität mittels EIM auf MOE ab.

Die beiden Dateien MoeAccess und NoMoeAccess werden nun im iSeries Navigator angezeigt. MOE verfügt über *ALL Berechtigung für die Datei MoeAccess und *USE Berechtigung für die Datei NoMoeAccess. Klickt Fred nun auf die Datei MoeAccess und benennt sie um, so funktioniert das einwandfrei. Klickt er aber auf die Datei NoMoeAccess und versucht, auch diese Datei umzubenennen, schlägt diese Operation fehl, da Fred nicht über die entsprechende Berechtigung verfügt. Dies alles geschieht, obwohl sich Fred nur ein einziges Mal mit seiner Windows 2000 Benutzer-ID auf seinem Laptop angemeldet hat.

OS/400 Konfiguration für Single Sign-On

Um einem System die Teilnahme in einer EIM SSO Umgebung zu ermöglichen, ist eine Konfiguration erforderlich, die dem System mitteilt, welchen Kerberos realm (Kerberos Server) es verwenden soll. In V5R2 steht über den iSeries Navigator ein Assistent für die Konfiguration des Network Authentication Service (NAS) zur Verfügung, mit dessen Hilfe sich diese Aufgabe relativ einfach erledigen lässt.

Der Systemadministrator muss überdies das System für die Benutzung eines bestimmten EIM Domain Controller konfigurieren. Der EIM Konfigurations Assistent (Abbildung 1) leistet wertvolle Unterstützung bei dieser Aufgabe. Der Assistent wird im iSeries Navigator durch einen Klick mit der rechten Maustaste auf den Ordner Network/Enterpise Identity Mapping/Configuration gestartet, danach kann aus dem Menü entweder Configure oder Reconfigure ausgewählt werden.

Der EIM Konfigurations Assistent geht davon aus, dass der Administrator eine EIM Konfiguration zum Erstellen einer SSO Umgebung für das Betriebssystem durchführen möchte. Er überprüft zuerst, ob Kerberos bereits konfiguriert wurde. Ist dies nicht der Fall, startet er den Network Authentication Service Assistenten. Abhängig davon, welche Client-Schnittstellen an der SSO Umgebung teilnehmen sollen, können zusätzliche Konfigurationsschritte erforderlich werden. So verfügt beispielsweise der iSeries Navigator über eine neue Auswahl zur Kerberos Authentifizierung für die Verbindungsschnittstelle. Bei der Konfiguration eines DRDA Zugriffs auf eine ferne Datenbankdatei kann nun selektiert werden, ob Kerberos zur Authentifizierung verwendet werden soll oder nicht. Auch der PC5250 Emulation muss mitgeteilt werden, ob Kerberos verwendet werden soll.

Weitere Details zur EIM Infrastruktur

Da wir nun einen kurzen Überblick über die Leistungsfähigkeit von EIM haben, ist es sicherlich interessant, einen tieferen Blick hinter die Kulissen zu werfen. Die iSeries EIM Strategie basiert auf Kerberos. Die zugehörige Infrastruktur selbst ist allerdings vollständig unabhängig von einem wie auch immer gearteten Benutzerverzeichnis. EIM erlaubt die Assoziation beliebiger User-IDs aus beliebigen Benutzerverzeichnissen mit sogenannten „EIM Identifiern“. Unabhängige Softwarenanbieter sind somit frei in der Entscheidung, basierend auf einem beliebigen Benutzerverzeichnis, heterogene über mehrere Plattformen ausgelegte Anwendungen zu entwickeln. Die EIM Infrastruktur wirkt hier im Vergleich zu früher deutlich kostensenkend, da es nun relativ einfach ist, Anwendungen zu entwickeln, die ein Benutzerverzeichnis zur Authentifizierung und ein anderes Benutzerverzeichnis zur Autorisierung verwenden.

Die unter EIM gespeicherten Daten repräsentieren Personen oder Instanzen innerhalb des Unternehmens und die mit ihnen assoziierten Benutzer-IDs aus den unterschiedlichsten Benutzerverzeichnissen. Die Identitäten selbst werden in EIM nicht definiert. Dies erspart die Notwendigkeit zur Synchronisation der Informationen aus den diversen Benutzerverzeichnissen mit den EIM Informationen.

EIM verwendet als Repository das Lightweight Directory Access Protocol (LDAP), das einen Zugriff auf verteilte Ressourcen gestattet. Da LDAP ein weit verbreiteter Standard ist, hat dadurch im Grunde annähernd jeder Host und jedes Endbenutzer-System die Möglichkeit, auf das EIM Repository zuzugreifen. Alles in allem gesehen ist es nicht besonders erstrebenswert, auf jedem System Informationen zur Abbildung korrespondierender Benutzerinformationen verwalten zu müssen. Dies sollte sinnvollerweise einmal zentral auf Basis des gesamten Netzwerks oder einer EIM Domäne geschehen. Ein EIM Domain Controller ist schlicht nichts weiter als ein LDAP Server, der das EIM LDAP Schema implementiert hat. Derzeit sind die letzten Versionen der IBM Directory Server aller eServer Plattformen in der Lage, als EIM Domain Controller zu fungieren. Für die Zukunft plant IBM die Unterstützung weiterer LDAP Server.

Die einzige schlechte Nachricht bezüglich EIM ist die Tatsache, dass es annähernd 40 APIs enthält. Allerdings werden bei der Entwicklung von Anwendungen, die EIM ausschließlich zur Abbildung von Identitäten einsetzen, nur ca. vier APIs benötigt. Die restlichen APIs stehen für die Entwicklung von Anwendungen zur Verfügung, die Verwaltungsfunktionen innerhalb EIM abdecken (z.B. iSeries Navigator oder Businesspartner-Anwendungen).

IBM’s EIM Entwicklungsziel bestand darin, Entwicklern und Administratoren die Funktionalität zur Verfügung zu stellen, ohne sie dabei zu zwingen, LDAP Experten zu werden. Somit umfassen die EIM APIs konsequenterweise die vorhandenen LDAP Client APIs (Abbildung 2).

Man könnte stattdessen natürlich auch die LDAP APIs direkt verwenden, aber das setzt – zum korrekten Aufbau einer SSO Umgebung ohne Regelverletzungen – ein ausgesprochen genaue Kenntnis von LDAP und dem EIM Schema voraus. Die Verwendung der EIM APIs ist hier erheblich zweckmäßiger.

EIM Daten müssen – wie alle anderen Daten – geschützt werden. Obwohl eventuelle Angreifer kaum in der Lage sein werden, die alleinige Kenntnis von EIM Informationen zum Schaden des Unternehmens einzusetzen, können diese Informationen doch von gewissem Wert für sie sein. Die in LDAP integrierten Sicherheitsmechanismen kontrollieren den Zugriff auf EIM Daten und die Implementierung stellt nicht einfach jedem, der danach fragt, Informationen über die Abbildung von Benutzer-IDs zur Verfügung.

Um den unterschiedlichsten administrativen Strategien in Unternehmen unterschiedlicher Größenordnung gerecht werden zu können, verfügt EIM über die erforderliche Flexibilität, entweder einer Person die gesamte Autorisierung für alle Ressourcen zu erteilen, oder aber die Autorisierung auf mehrere Personen mit abgegrenzten Aufgabenbereichen zu verteilen. Dies geschieht über EIM APIs zur Konfiguration und Verwaltung von EIM Daten. Sie gestatten eine Bildung von LDAP Gruppen und die Verwaltung der LDAP Security Mechanismen. Um Administratoren und Programmierern eine Einarbeitung in die LDAP Security Mechanismen zu ersparen, stellt IBM zusätzliche APIs zur Verwaltung der LDAP Gruppen (Hinzufügen oder Entfernen von Benutzern) zur Verfügung. Diese Aufgabe lässt sich allerdings auch über die Auswahl Users und Groups im iSeries Navigator Enterprise Identity Management folder unter „Netzwerkoptionen“ erledigen.

Administratoren können die Abbildung von EIM Identitätsinformationen entweder aus Netzwerksicht oder aber im iSeries Navigator über Users und Groups verwalten. Beim Erstellen oder Verwalten von Benutzerprofilen kann der Administrator auf eine Liste der EIM Identifier für die EIM Domäne zurückgreifen, der ein System zugeordnet ist (Abbildung 3) und dann das gerade bearbeitete Benutzerprofil einem bestimmten Identifier zuordnen.

Um die Entscheidung zu erleichtern, welchem EIM Identifier ein Benutzerprofil zuzuordnen ist, können alle mit einem EIM Identifier assoziierten Benutzerprofile angezeigt werden (Abbildung 4).

Bei Löschung eines Benutzerprofils werden alle Verbindungen dieses Benutzers zu EIM Identifiern in der Domäne gelöscht, in der sich das System befindet.

Für jeden etwas

Mit der Einführung von EIM sollten die Aufgaben für jedermann leichter werden. Sicher, EIM bedeutet für Administratoren einen gewissen zusätzlichen Arbeitsaufwand. In Relation zu dem Aufwand aber, der bei der Verwaltung von unterschiedlichsten Sicherheitsmechanismen für im gesamten Unternehmen verteilte Datenbestände betrieben werden muss, ist der durch EIM anfallende zusätzliche Aufwand eher klein und sicherlich die Investition wert. Die Aufgaben der Administratoren werden nach erfolgter Implementierung erheblich erleichtert, weil nun an einer zentralen Stelle alle Informationen über die unternehmensweiten Benutzer-IDs eines bestimmten Benutzers zusammengeführt sind.

EIM-unterstützte SSO-Umgebungen können zu gesteigerter Produktivität der Benutzer und verminderter Abhängigkeit von den benutzerunterstützenden Funktionen im Unternehmen dienen. Immer wiederkehrende Aktivitäten wie das Zurücksetzen von Passwörtern und die Synchronisation von Benutzer-ID und Passwort-Daten gehören weitgehend der Vergangenheit an. Überdies profitieren auch ISVs von EIM. Sie können sich auf ihre Produktentwicklung konzentrieren, ohne dabei Zeit und Aufwand in den Aufbau eigener Benutzerregistrierungen und zugehöriger Sicherheitsmechanismen investieren zu müssen.

Übersetzt und für den deutschsprachigen Markt überarbeitet von Joachim Riener