![[GRAFIK]](46-1.jpg)
Ein SSO-System muss auf dem Client die Kommunikation der relevanten Protokolle verstehen, auf denen sekundäre Logins ablaufen.
Single Sign-on (SSO) ist eine feine Sache. Glaubt man einigen Marketingabteilungen, dann installiere man nur ein oder zwei zusätzliche Programme und schon sind die vielen lästigen Passwortabfragen verschwunden und die Sicherheit im Netzwerk hat sich auch noch drastisch erhöht. Bei wem dieses Szenario zutrifft, der hat Glück und wahrscheinlich auch eine sehr homogene IT-Landschaft. In der Mehrzahl aller Fälle dürften jedoch komplexe Anpassungen im Umfeld notwendig sein, um dem Paradies näher zu kommen.
Single Sign-on bedeutet, dass sich ein Nutzer nur einmal bei einem System-Entry-Service anmeldet und dann alle Dienste und Ressourcen (für die er eine Berechtigung besitzt) ohne weitere Authentifizierung bereitstehen. Daraus ergeben sich drei grundlegende Anforderungen an eine Single-Sign-on-Lösung:
Welcher Aufwand mit der Umsetzung dieser Punkte letztendlich verbunden ist, hängt wesentlich von der Komplexität und Vielfalt der einzubeziehenden Systeme ab. Gerade in heterogenen Netzwerken ist es oft wünschenswert, vorhandene redundante Strukturen zu beseitigen und mittels eines zentralen Benutzerverzeichnisses und einer einmaligen Authentifizierung die Zugriffsverwaltung zu vereinfachen. Allerdings sind es eben auch diese heterogenen Systeme, welche nur selten einer einheitlichen Architektur von Protokoll- und Anwendungsschnittstelle folgen.
Vor jeder Implementierung sind als erstes konkrete Überlegungen anzustellen, wie das SSO-System in die bestehenden Arbeitsabläufe zu integrieren ist. Dazu zählen neben der Aufnahme aller betroffenen Systeme und Anwendungen auch die bisher praktizierten Authentifizierungs- und Autorisierungsverfahren inklusive der Benutzerinformationen und ihrer Speicherorte. Aus den erfassten Daten gilt es Wege abzuleiten, wie SSO im konkreten Fall sicher, robust und zuverlässig integriert werden kann, zum Beispiel durch die Definition einer Sicherheits-Policy mit globalem Rechte- und Rollenkonzept (vgl. Kasten).
----------Anfang Textkasten----------
----------Ende Textkasten----------
Im Zentrum jeder Lösung sollte eine zentrale Benutzerverwaltung stehen, in der die Benutzerdaten, Regeln und Rollen aller wichtigen Zielsysteme zusammenfließen. Häufig werden diese Funktionen durch einen unternehmensweiten Verzeichnisdienst erfüllt, der sich über Lightweight Directory Access Protocol (LDAP) ansprechen lässt. LDAP hat sich mittlerweile als Standard etabliert und viele Applikationen bringen bereits eine passende Schnittstelle mit. LDAP hat auch den Weg in Verzeichnisse wie Novell Directory Services (NDS) oder Microsofts Active Directory gefunden.
Neben den allgemeinen Benutzerinformationen speichert das zentrale Verzeichnis auch die Credentials und Privilegien für verschiedene Anwendungen sowie digitale Zertifikate. Die Applikationen können dann die notwendigen Autorisierungsinformationen zum entsprechenden User direkt aus dem Verzeichnis lesen und darüber den Zugang zu ihren Daten regulieren.
Lassen sich die Schnittstellen aller beteiligten Anwendungen nicht in ein gemeinsames Verzeichnis zusammenführen, so kann die Verteilung der Benutzerinformationen durch Agenten aus dem zentralen Directory heraus in die individuellen User-Datenbanken erfolgen. Damit ist zwar die Synchronisation der Authentifizierungsdaten gewährleistet, ihre Verteilung auf verschiedene Systeme und Orte kann aber weiterhin eine Einschränkung der Sicherheit bedeuten.
Die zentrale Benutzeradministration bereitet parallel den Weg, Passwörter durch digitale Zertifikate zu ersetzen, mit denen sich die Zugriffskontrolle noch sicherer gestaltet und die darüber hinaus einen sicheren Schlüsselaustausch zur Chiffrierung der Übertragungsdaten und die Integrität der Übertragungsinhalte garantieren. In einer Gesamtlösung ist es sinnvoll, innerhalb des Unternehmens eine eigene PKI aufzubauen. Neben dem Einsatz für SSL-Verbindungen kann sie gleichzeitig zum Verschlüsseln und Signieren von E-Mails und für das Zutrittskontrollsystem verwendet werden.
Je nach Unterstützung durch die Applikationen und den Anforderungen der Sicherheits-Policy kann auch die Authentifizierung selbst auf digitalen Zertifikaten basieren. Spezielle Privilegien und Rollenprofile lassen sich ebenfalls an Zertifikate binden (Attribut-Zertifikate).
Der Einsatz von "Trusted Third Party"-Zertifikaten (TTP) ohne eigene PKI ist nur bedingt zu empfehlen, da viele Abläufe dann nicht ohne weiteres automatisiert werden können. In einer eigenen PKI-Umgebung lassen sich Zertifikate schneller sperren und die Folgen haben sofort Auswirkungen auf das gesamte Netzwerk. Nicht zuletzt ist eine eigene PKI auch erheblich kostengünstiger.
Die verschiedenen Ansätze der existierenden SSO-Systeme lassen sich nur bedingt kategorisieren. Es existiert kein wirklicher Standard und die meisten Hersteller ziehen eigene, proprietäre Schnittstellen den offenen und standardisierten Schnittstellen vor. Betrachtet man die vorhandenen Systeme und Anwendungen seitens des Clients, so sind für die Umsetzung einer SSO-Lösung zwei Punkte wesentlich: die Kommunikations- und die Authentifizierungsschnittstelle.
Der Zugriff auf Ressourcen im Netzwerk kann auf unterschiedlichen Ports und Protokollen basieren und muss zwischen Client und Server harmonisieren. Standarddienste und -anwendungen wie Mail, News und Webzugriffe haben definierte Ports über Betriebssystemgrenzen hinweg. Zugriffe auf Legacy-Anwendungen über nicht standardisierte Protokolle sind jedoch uneinheitlich und stellen besondere Anforderungen an eine SSO-Umsetzung.
Letztlich muss das SSO-System Client-seitig alle verwendeten Kommunikationsprotokolle der eingebundenen Applikationen unterstützen, um darüber die Authentifizierungsinformationen einzustreuen. Die Basis hierfür kann eine einheitliche Programmierschnittstelle sein, die ein Interface zu den Authentifizierungsdiensten bereitstellt. Das primäre Login zum System wird dann durch das Login zum SSO-Authentifizierungsdienst ersetzt. Danach erfolgen alle weiteren Logins zu den Hauptapplikationen automatisch durch den SSO-Dienst.
Ein SSO-System muss auf dem Client die Kommunikation der
relevanten Protokolle verstehen, auf denen sekundäre Logins
ablaufen.
Auch die einzubindenden Netzwerk-Ressourcen/-Applikationen müssen mit dem SSO-System kommunizieren und die empfangenen User-Credentials verarbeiten können. Das setzt ein Verständnis der verwendeten Protokolle und Mechanismen des SSO-Systems voraus und bedingt gegebenenfalls Anpassungen an den Anwendungen
Web-Applikationen lassen sich mit relativ wenig Aufwand integrieren, da sie über ein standardisiertes Protokoll (HTTP Basic Authentication) senden und empfangen. Die Authentifizierungsinformationen können daher direkt in den HTML-Strom eingefügt werden, nachdem vorher ein Parser die entsprechenden Stellen gefunden hat. Weitere Credentials (Session-Tickets, Rollen und Rechte) lassen sich in XML-Dateien (s. a. S. 20) verpacken und verschlüsselt an die Applikationen senden.
![[GRAFIK]](46-2.jpg)
Nachdem es Login-Versuche aufgefangen hat, muss das SSO-System
den Netzwerkressourcen die entsprechenden Zugangsinformationen
übermitteln.
Im Mittelpunkt dieses Ansatzes steht eine zentrale Authentifizierungs- und Autorisierungsinstanz, welche die gesamte Session des Users steuert. Dazu ist eine enge Verknüpfung mit den darunter liegenden Betriebssystemen notwendig. Die Protokolle und Application Programming Interfaces (APIs) aller Anwendungen müssen einheitlichen Kriterien folgen und integraler Bestandteil der Softwarearchitektur sein. Nur dann sind die beteiligten Komponenten des Gesamtsystems in der Lage, ein vollständiges, plattformübergreifendes SSO-System abzubilden.
Die zentrale Instanz vergibt an alle Clients, die sich bei ihr authentifizieren, ein Session-Ticket, das diese bei Ressourcenzugriffen identifiziert. Der Ticket-Server stellt somit eine Vertrauensinstanz für die Applikationen dar. Der zentrale Server kann das Ticket anhand seiner gespeicherten Daten oder durch eine Signatur verifizieren, da er es selbst generiert hat. Anschließend liest er die Berechtigungen und Privilegien des Nutzers für die entsprechende Anwendung aus der zentralen Benutzerverwaltung und generiert ein Zugangs-Ticket. Die Anwendung erhält diese Credentials, prüft möglicherweise die Gültigkeit und kann damit den Nutzer identifizieren. Das Zugangs-Ticket verfällt mit dem Beenden der Applikation.
Es gibt verschiedene Variationen dieses Verfahrens; alle setzen jedoch einheitliche Kommunikationsprotokolle und Authentifizierungsschnittstellen voraus. In heterogenen Umgebungen sind diese Bedingungen jedoch nur selten vorzufinden. Dort müssen eventuell einzelne Anwendungen umgeschrieben und angepasst werden. Der damit verbundene Aufwand lässt dieses Konzept in der Umsetzung unpraktisch erscheinen und bedingt langfristig einen hohen Wartungsaufwand.
Unter dem Gesichtspunkt von Transparenz und leichter Administrierbarkeit, insbesondere bei Verschmelzung der Authentifizierungsschnittstellen mit dem Betriebssystem, stellt dieser Ansatz jedoch die vollständigste Umsetzung von Single Sign-on dar. Verbreitete Lösungen von zentralisierten Ticket-Systemen bauen häufig auf das am MIT entwickelte Kerberos-Protokoll auf, so zum Beispiel das Distributed Computing Environment der Open Software Foundation, das entworfen und entwickelt wurde, um eine heterogene Menge von vernetzten Rechnern in eine einzige logische Rechenmaschine zu verwandeln.
Mit Windows 2000 findet sich erstmals auf Basis einer verbreiteten Plattform eine Umsetzung des zentralisierten SSO-Konzeptes als integraler Bestandteil eines Betriebssystems. Dazu wurden die Protokolle Kerberos und SSL in der Architektur verankert und gestatten auch in gemischten Netzwerken die Bereitstellung dieses Dienstes. Microsofts SNA-Server soll diese Funktion mithilfe proprietärer Protokolle auf Mainframe-Umgebungen ausweiten. Alle Anwendungen, die das BackOffice-Logo tragen, unterstützen Windows-2000-SSO als systemeigenen Bestandteil und stellen so eine gewisse Verfügbarkeit von SSO-gestützten Anwendungen sicher. Die zentrale Benutzerverwaltung basiert hierbei auf dem Active Directory und bedient neben den Domain-Controllern auch die Autorisierungsserver (Key Distribution Center, KDC) mit Benutzerinformationen und Zertifikaten. Der dafür benötigte Certificate Service ist im Advanced Server integriert.
![[GRAFIK]](46-3.jpg)
SSO-Ablauf bei Ticket-basierten Systemen
Unter dieses Konzept fallen alle Systeme, die nachträglich über bereits vorhandene Applikationsschnittstellen und Kommunikationsprotokolle installiert werden und selbst in der Anwendungsschicht angesiedelt sind. Im engeren Sinne stellen sie keinen echten Teil des Gesamtsystems dar, noch interagieren sie als Komponente des Systems. Vielmehr greifen sie direkt – oftmals ohne "Wissen" der betroffenen Komponenten – in die vorhandenen Kommunikationskanäle und Authentifizierungswege ein und verteilen darüber die gespeicherten Benutzerinformationen.
Die Minimalisten unter diesen Vertretern begnügen sich mit einfacher Automation und Synchronisation von Passwörtern und erhöhen damit zumindest den Komfort für die Benutzer. Gesteuert wird die Authentifizierung über einen Hintergrundprozess, der sämtliche Windows-Events überwacht (WindowsWatching). Das funktioniert allerdings nur mit Web- und GUI-Anwendungen – und mit Letzteren meist nur auf Microsoft-Plattformen.
Verlangt eine Anwendung vom Benutzer eine Authentifizierung und öffnet dazu ein Dialog-Fenster, so reagiert prompt der Hintergrundprozess, füllt die Eingabefelder mit den Authentifizierungsdaten und simuliert den OK-Button (SnapIn).
Dieser Ablauf kann zum Beispiel über Skripte gesteuert werden und ist für jede Anwendung individuell konfigurierbar. Andere Hersteller statten ihre SSO-Systeme mit komfortablen Tools aus, die eine Integration von Anwendungen per Mausklick ermöglichen. Auch hinsichtlich der Datenhaltung für die User-Credentials gibt es unterschiedliche Ansätze, wie zum Beispiel lokaler Cache des zentralen Verzeichnisses, lokaler Passwort-Store oder externe Datenträger (Smartcards oder USB-Token). Zusätzlich bieten einige Hersteller von SnapIn-Lösungen auf ihren Websites Anpassungen für verbreitete Applikationen zum Download an, mit denen diese nachträglich direkt in das SSO-System integriert werden können (SSO-Enabled).
Zu den kommerziellen Produkten auf Basis dieses Konzeptes zählen unter anderem Novell SSO, IBM Tivoli GlobalSignOn und Entrust SSO. Novells Lösung verlangt die Einbindung des eDirectorys als zentrale Benutzerverwaltung sowie die Installation der Netware Software auf allen Clients, die am SSO-System partizipieren sollen. Zusätzlich bietet Novell mit der Software "v-Go" eine erweiterte Funktionalität bei der Integration von Legacy-Applikationen.
Auch Entrust führt eine Single-Sign-on Lösung im Produktkatalog. Sie baut vollständig auf der hauseigenen PKI-Software auf und benötigt für den breiten Einsatz noch weitere, zum Teil frei erhältliche Desktop- und Server-Tools. Die Einbindung von "Entrust-Enabled"-Applikationen wie Oracle (ab Version 8.1.7) ermöglicht eine zertifikatsbasierte Authentifizierung auch für Legacy-Anwendungen. Die Zertifikate enthalten zusätzliche User-Credentials (Attributzertifikate), mit denen Privilegien und Rechte verknüpft werden können.
----------Anfang Textkasten----------
Unter anderem folgende Unternehmen haben Single-Sign-on-Software im Programm:
| Axent/Symantec | ![[externer Link]](../../../../images/link.gif) www.axent.de |
|
| Computer Associates | www.ca.com |
|
| Entrust | www.entrust.com |
|
| Evidian | www.evidian.com |
|
| Novell | www.novell.de |
|
| RSA Security | www.rsasecurity.com |
|
| Symas | www.symas.com |
|
| Systor | www.systor.de |
|
| Tivoli | www.tivoli.com |
|
| Unisys | www.unisys.com |
|
| Utimaco Safeware | www.utimaco.de
|
----------Ende Textkasten----------
Der Ansatz solcher aufgesetzten Systeme ist sehr pragmatisch und lässt sich in kleinen Umgebungen einfach und schnell realisieren. Die Abhängigkeit von grafischen User-Interfaces schränkt die Unterstützung auf bestimmte Plattformen ein, was dem Einsatz in heterogenen Umgebungen wieder abträglich ist. Zusätzlich muss für alle unterstützten Applikationen der Software-Agent gesondert auf jedem Client konfiguriert werden.
Für größere Umgebungen stellt dieses SnapIn-Konzept nur eine unzureichende Lösung dar: Es fehlt die Integrierbarkeit kommandozeilenorientierter Anwendungen, wie sie in der Unix-Welt häufig vorkommen. Die nachträgliche Anpassung dieser Anwendungen dürfte sich mit jeder neuen Version zum Bumerang entwickeln und permanent Kosten erzeugen. Meist stützt sich das gesamte SSO-System noch auf weitere Produkte desselben Herstellers (Verzeichnis, PKI usw.) und führt dann schnell zur Monokultur innerhalb der IT-Landschaft.
Zudem erscheint die gesamte Kommunikation innerhalb des SSO-Systems durch den Einsatz proprietärer Protokolle und Schnittstellen wenig transparent. Wie sicher die Passwörter im Store gespeichert sind und welche kryptographische Stärke die automatisch generierten Keys tatsächlich aufweisen, bleibt weitestgehend verdeckt.
![[GRAFIK]](46-4.jpg)
SSO-Ablauf bei SnapIn-Systemen
Die Open Group hat 1997 mit der Preliminary Specification zu Open Single Sign-on Service (XSSO) [2] ein Rahmenwerk für die Vereinheitlichung von Authentifizierungsdiensten definiert. Dazu spezifizierte sie einheitliche Application Programming Interfaces für die Entwicklung von End-User Anwendungen, die Sign-on, Sign-off und Operationen für Passwort-Änderungen bereitstellen. Das Framework berücksichtigt folgende Aspekte:
Die Spezifikation beschreibt SSO in zwei Schritten, dem primären und dem sekundären Sign-on. Beide werden mit Pluggable Authentication Modules, dem PAM Service [3] als Teil der XSSO Service API realisiert.
Das Pluggable Authentication Module Framework selbst wurde von Sun entwickelt und erstmals in Solaris 2.3 integriert. Es trennt die einzelnen Anwendungen von den Mechanismen zur Benutzerauthentifizierung. Die modulare Konzeption ermöglicht eine hohe Konfigurierbarkeit der Gesamtlösung und Austauschbarkeit der verwendeten Mechanismen. Die aufrufende Applikation ist selbst für die Implementation des Dialogs zum End-User verantwortlich. Das macht PAM unabhängig von User-Interfaces. Wesentliche Vorteile von PAM sind:
PAM unterstützt fünf verschiedene Typen von Service-Modulen:
PAM ist mittlerweile neben Solaris auch auf HP Unix und Linux vertreten. Es existieren bereits zahlreiche Module, darunter auch für Smartcard-Logins und NT-Domain-Anmeldung.
![[GRAFIK]](46-5.jpg)
Die Ebenen der PAM-Authentifizierung
Zu Beginn einer Session authentifiziert sich der Nutzer üblicherweise über eine Betriebssystem-Shell an der Workstation. Er interagiert dabei über ein Interface des System Entry Service (Logon User Interface), der die Session etabliert. Als Teil dieses Services fungiert der primäre Mechanismus und übernimmt die Authentifizierung des Nutzers. Misslingt diese, ist keinerlei Zugriff auf die Komponenten des Systems gestattet.
Der System Entry Service ist verantwortlich für:
Der sekundäre Sign-on wird über bereits gespeicherte Daten durch den XSSO Service gesteuert und läuft automatisch ab.
Leider sind Implementationen auf dieser Basis bislang nur selten zu finden. Dabei sind die Voraussetzungen hierfür bereits vorhanden: Die Definition eines geeigneten plattformübergreifenden Frameworks ist mit dem X/Open Single Sign-on Service gegeben und wird voraussichtlich als Basis in eine zukünftigen Standardisierung einfließen.
----------Anfang Textkasten----------
Hat man es geschafft, ein effektives und sicheres SSO-System in seine IT-Landschaft zu integrieren, so müssen damit noch immer keine Auswirkungen auf die Gesamtsicherheit verbunden sein. Denn zu diesem System gehört letztendlich auch der Anwender selbst, dessen Arbeitsstation als das schwächste Glied in der Kette und damit das primäre Schutzziel zu betrachten ist. Ursprünglich ist SSO mit dem Ziel der Reduktion von passwortbedingten Sicherheitsproblemen angetreten, doch mittlerweile werden die Anforderungen durch neue Formen der Authentifizierung erweitert, zum Beispiel auf Basis von digitalen Zertifikaten, Smartcards, OTPs und biometrischen Verfahren.
Ein Mehrwert für die zugrunde liegende Sicherheitsarchitektur resultiert allerdings nicht automatisch aus der Einbindung solcher Formen, sondern nur durch eine sinnvolle Integration in die aktuellen Arbeitsabläufe. Das heißt, der Anwender darf darin keinen zusätzlichen Aufwand oder gar eine Behinderung in seinem Arbeitsprozess sehen, sondern sollte zur aktiven Unterstützung angeregt werden. Mit Smartcards könnte das beispielsweise so aussehen, dass die Entscheidung zugunsten von Multiapplikationskarten fällt, die gleichzeitig für das Zutrittssystem und als Geldbörse in der Cafeteria notwendig sind. Verlässt der Anwender seinen Arbeitsplatz, so ist er immer gezwungen, die Karte aus dem Leser zu entfernen und damit die Workstation zu blockieren.
----------Ende Textkasten----------
Zweifellos wird der Bedarf nach Vereinfachung von Authentifizierungsprozeduren und damit nach Single Sign-on weiter wachsen. Für viele IT-Systeme bedeutet das komplexe Anpassungen. Marketingversprechen wie "leichte Implementation" oder gar "out-of-the-box" sind nur in kleineren und zudem homogenen Landschaften einzuhalten. Grund dafür sind fehlende Standards und die mangelnde Unterstützung einheitlicher Authentifizierungsschnittstellen, insbesondere bei plattformübergreifenden heterogenen Infrastrukturen. Hier folgt der Anschaffung eines Softwarepaketes zwangsläufig hoher integrativer Aufwand zur Anpassung an die lokalen Gegebenheiten.
Viele SnapIn-Systeme verfügen nur über einen Windows-Client und bedingen oft den Kauf zusätzlicher Komponenten von demselben Hersteller, auf deren Funktionen sie aufbauen. Das kann nicht immer gewünscht sein, wenn damit bisher verwendete Software überflüssig wird und anfänglich übersehener zusätzlicher Aufwand und weitere Kosten entstehen.
Homogene IT-Infrastrukturen vereinfachen die Integration eines Single-Sign-on-Verfahrens erheblich, sind aber in der Praxis nur selten anzutreffen, was an ihrer einseitigen, meist herstellergebundenen Ausrichtung liegt. Mit dem Verzicht auf proprietäre Entwicklungen und der ausschließlichen Verwendung offener und standardisierter Schnittstellen, könnte der Aufwand bei der Umsetzung unternehmensweiter SSO-Lösungen merklich reduziert werden.
Thomas Weber ist Berater bei der Trivadis Rüsselsheim/Zürich.
www.opengroup.org/tech/dce/ www.opengroup.org/publications/catalog/p702.htm www.sun.com/solaris/pam/© SecuMedia-Verlags-GmbH, D-55205 Ingelheim,
KES 3/2001, Seite 46
