Single-Sign-on-Konzepte
Plädoyer für eine föderale Struktur
Portale und serviceorientierte Architekturen (SOA) erfordern eine Integration und Vereinheitlichung des Identity- und Access-Managements (IAM). Single Sign-on (SSO) erhöht den Anwenderkomfort, macht die Administration des IAM transparent und reduziert den Verwaltungsaufwand.
Mit SSO lässt sich ein unternehmensweit einheitliches Vorgehen bei der Verwaltung von
Benutzerinformationen und zum Teil bei der Rechteverwaltung durchsetzen. Beim Konzept des SSO
müssen Autorisierung und Authentisierung streng getrennt behandelt werden. In einer föderalen
Struktur wird nur die Authentisierung (Login) zentralisiert, die Autorisierung (Rechte und
Rollenvergabe) aber verbleibt im fachlichen Kontext der Applikationen, denn eine gemeinsame
Rollenverwaltung für alle Anwendungen erweist sich in der Praxis häufig als kaum beherrschbar. Die
Beschränkung auf die Zentralisierung der Authentisierung hat den Vorteil, dass die Änderungen an
den Applikationen punktuell und minimal invasiv ausfallen.
Voraussetzung für jede SSO-Lösung ist die zentrale Verwaltung von Benutzerdaten. Das Objekt zur
Beschreibung von Benutzern hat eine eindeutige und unveränderbare User-ID. Hinzu kommen ein
lesbarer Distinguished Name (DN) – dieser ist eindeutig, hat aber nicht die Funktion des Schlüssels
– sowie ein Kennzeichen, das anzeigt, ob das Objekt aktiv ist oder nicht.
Der DN kann sich durch Restrukturierung der Organisation oder Namenswechsel ändern. Für die
Identifizierung des Users in den Anwendungen wird die User-ID genutzt. Das Aktivkennzeichen ist
entscheidend für das zentrale und sofortige Aktivieren beziehungsweise Entziehen von
Berechtigungen. Die User Informationen wiederum werden in einem Directory Service verwaltet (LDAP,
ADS und so weiter).
Für SSO erweist sich die Weitergabe der Benutzerinformation an die Anwendungen als essentiell.
Realisiert wird sie durch einen Ticketservice. Ein Ticketservice vereinheitlicht den Wechsel von
einer Anwendung in die nächste. Er wird über HTTP(s) angesprochen und lässt sich in vorhandenen
IT-Landschaften wie andere gesicherte Intranetanwendungen behandeln – etwa mit Firewalls sichern
und Restriktionen unterwerfen. Ein Ticket ist in diesem Fall ein einmaliger Schlüssel, der zwischen
Anwendungen weitergereicht wird. Über das Ticket können die Benutzerdaten beim Ticketservice
abgeholt werden.
Das Anmeldeverfahren macht eine Softwareanpassung der zu integrierenden Anwendungen notwendig,
denn diese müssen – anstelle eines Logins – die Anmeldung durch den Ticketservice akzeptieren.
Lösungsanbieter wie SAP, Oracle oder Siebel haben bereits eine Schnittstelle zu den verschiedenen
Ticketservices in ihre Produkte integriert. Für SOA-Architekturen empfiehlt sich die Schnittstelle
Security Assertion Markup Language (SAML), die mittlerweile viele Lösungen verstehen. SAML Version
1.1 wird von Microsoft-Lösungen unterstützt, momentan ist die Version 2.0 noch nicht Standard.
Individualanwendungen lassen sich am einfachsten über die jeweilige spezielle
Standard-Implementierung anbinden, etwa Java mit JAAS.
Open Source und Sicherheit stehen nicht im Widerspruch zueinander. Im Gegenteil: Durch die
ständige kritische Beobachtung und den allgemein zugänglichen Quellcode werden Fehler häufig früher
erkannt und behoben als in kommerziellen Systemen. Schwachstellen werden offen diskutiert und
geschlossen, weil kein monetäres Interesse vorhanden ist. Da Sicherheitslösungen nicht auf
Geheimhaltung der Implementierung beruhen, sondern auf der Zuverlässigkeit von Algorithmen, sind
eine große Verbreitung und eine ständige Verbesserung Garanten für Sicherheit. Einige
Open-Source-Lösungen sind aus Referenz-implementierungen des entsprechenden Sicherheitsstandards
hervorgegangen.
Ein SSO-Lösungsszenario mit Open-Source-Produkten umfasst OpenLDAP als Directory Service und
JA-SIG Central Authentication Service (CAS) als Ticketservice. CAS erfreut sich breiter
Unterstützung, sowohl durch Open-Source-Produkte als auch durch kommerzielle Anbieter.
Ein alternativer Open-Source-Ticketservice ist Shibboleth. Beide Lösungen verwenden die gängigen
Sicherheitsstandards (darunter SAML, JAAS, PAM). Shibboleth zielt auf unternehmensübergreifende
Sicherheitslösungen. CAS verzichtet auf diesen Aspekt, ist dadurch aber leichter handhabbar und
ideal für die Einbindung von Java-Individual-Lösungen, da es direkt von vielen Applikationsservern
unterstützt wird.
Beispielszenario
Ein Benutzer verwendet zwei Web-Applikationen in einem Portal (siehe Grafik). Er ist angemeldet
und über LDAP authentisiert. Der Benutzer arbeitet mit Anwendung Nr. 1 und will zu Anwendung Nr. 2
wechseln. Der Ablauf:
Der Benutzer wählt die Anwendung 2 aus. Der Ticketservice ist als Proxy konfiguriert und leitet
den Aufruf deshalb nicht direkt an die Zielanwendung weiter. Der Ticketservice ergänzt den Aufruf
der Applikation mit einem Service-Ticket. Ein Service-Ticket ist ein einmalig gültiger Schlüssel,
mit dem die Zielapplikation am Ticketservice eine Rückfrage stellen kann.
Anwendung 2 meldet sich mit dem Service-Ticket beim Ticketservice und bekommt dafür das
Benutzerobjekt geliefert. Der Ticketservice löscht das Ticket, damit es nicht noch mal verwendet
werden kann. Die Anwendung autorisiert den Benutzer gemäß den eigenen Einstellungen.
Damit ist die Weitergabe des Benutzerobjekts erfolgt. Weitere Aspekte der Architektur: Die
Anwendungen sind entkoppelt, aber die Navigationswege zwischen ihnen können zentral im
Ticketservice eingesehen werden. Die Anwendungen kommunizieren in beide Richtungen mit dem
Ticketservice – immer über SSL. Das vollständige Protokoll, das hier nur skizziert ist, hat in
Kombination mit SSL ein sehr hohes Sicherheitsniveau, das beispielsweise "Man-in-the-Middle"
-Attacken unmöglich macht. Die Änderung der Anwendungen ist auf die Anmeldung beschränkt und damit
minimal invasiv. Dies bedeutet, dass die Anpassung nicht zu weit reichenden Änderungen der
Applikationen führt. Die Performance der Anwendung bleibt unbeeinflusst, da die Logik und die
Ablage der Rollen und Rechte unverändert bleiben. Die Hardwarekosten sind gering, und es wird nur
ein Ticketserver benötigt, der als Proxy für die Weiterleitung unter den Anwendungen dient.
Fazit
Voraussetzung für SSO ist die Trennung von Autorisierung und Authentisierung. Ein schrittweises
Vorgehen unter Einsatz von Open-Source-Lösungen minimiert die Kosten. Das vorgeschlagene Szenario
unterstützt alle Authentisierungsverfahren.
Wenn die zu integrierenden Anwendungen analysiert sind und die Architektur an Standards
ausgelegt wurde, ist technisch kaum mit Problemen zu rechnen. Es bleiben jedoch projektbezogene
Herausforderungen: Die Konflikte der beteiligten Interessengruppen sind in der Regel
problematischer als die Technik.
Lesen Sie mehr zum Thema
