Single Sign-On mit Kerberos

Kerberos ist ein im RFC 1510 der IEEE definierter Standard für die Authentifizierung. Im Gegensatz beispielsweise zum NTLM-Verfahren wird das Protokoll bei vielen Plattformen unterstützt. Besonders interessant dabei ist, dass Novell unlängst zwei neue Komponenten für die Unterstützung von Kerberos vorgestellt hat. Außerdem gibt es zunehmend mehr Unternehmen, die sich Gedanken machen über die Rolle, die Kerberos in ihrer IT-Strategie für Single Sign-On und für End-To-End-Security spielen soll.

Verschiedene Aspekte rund um Kerberos werden im Schwerpunkt dieses Hefts diskutiert. Dazu zählen eine grundsätzliche Betrachtung der Hintergründe für die vermehrte Aufmerksamkeit, die Kerberos nun erhält, ein Überblick über die Funktionsweise, ein Artikel zur Nutzbarkeit von Kerberos für die Authentifizierung in Anwendungen sowie Ausführungen zur Interoperabilität, zur Konfiguration, zu Tools für Kerberos und zum Troubleshooting.

Kerberos und Single Sign-On

Einer der Bereiche, in denen Kerberos zunehmend wichtig wird, ist das Single Sign-On. Kerberos ist ein standardisierter Authentifizierungsmechanismus, mit dem einerseits die Authentifizierung am System und andererseits an Diensten durchgeführt werden kann. Dazu wird mit so genannten Tickets gearbeitet, die Zugriffe erlauben. Es wird zwischen dem TGT (Ticket Granting Ticket), das bei der ersten Authentifizierung gegenüber Kerberos ausgestellt wird, und den Service Tickets für den Zugriff auf Dienste wie beispielsweise Datenbanken und andere Anwendungen unterschieden.

Da die Protokolle für die Anforderung von Tickets und die Struktur der Tickets standardisiert sind, können die Tickets auch bei Kerberos-Servern angefordert werden, die auf anderen Plattformen laufen – soweit es dabei keine Detailprobleme gibt, die so etwas verhindern. Auf das Thema der Interoperabilität wird noch in einem gesonderten Artikel eingegangen.

Als Voraussetzung dafür, dass ein Benutzer Tickets bei einem so genannten KDC – dem Kerberos Key Distribution Center, das Tickets ausstellt – anfordern kann, muss diese Komponente den Benutzer kennen. Dazu arbeitet ein KDC mit einem Verzeichnisdienst zusammen, im Fall von Windows 2000 Server und Windows Server 2003 mit dem Active Directory. In Novells neuer Implementierung wird dagegen, wenig überraschend, mit dem eDirectory gearbeitet. Eine Single Sign-On-Lösung auf Basis von Kerberos setzt damit mehrere Komponenten voraus:

• Einen zentralen Verzeichnisdienst, gegen den das KDC arbeitet.

• Ein KDC als Komponente, die Ticketanforderungen bearbeitet und Tickets ausstellt und damit auch die Authentifizierung übernimmt.

• Clients, die Kerberos-Anforderungen an einen KDC senden können.

• Dienste, die Kerberos-Tickets verarbeiten können.

Allerdings sind für die Umsetzung etliche Detailprobleme zu lösen. Abgesehen von unterschiedlichen Umsetzungen der Standards stellt sich beispielsweise die Herausforderung der Lokalisierung von KDCs für die Authentifizierung. In Windows-Umgebungen werden spezifische Informationen in den Tickets benötigt. Oft geht es aber auch darum, mehrere bestehende Kerberos-Infrastrukturen zu integrieren. In diesem Fall müssen Vertrauensstellungen zwischen den so genannten Kerberos-Realms aufgebaut werden.

Trotz der technischen Herausforderungen ist Kerberos ein interessanter Ansatz zur Realisierung eines Single Sign-Ons innerhalb von Unternehmen – allerdings bei weitem nicht der einzige Ansatz. Die direkte Alternative ist X.509, also die Nutzung digitaler Zertifikate. Der Vorteil ist die Einsetzbarkeit auch über Unternehmensgrenzen hinaus und für verschiedene zusätzliche Funktionen wie die E-Mail-Verschlüsselung mit S/MIME.

Außerdem gibt es mit spezialisierten Single Sign-On-Lösungen, bei denen Credentials (Authentifizierungsnachweise) für verschiedene Systeme gespeichert und im Hintergrund an die Anwendungen übergeben werden, ausgereifte Optionen, die allerdings nicht zu einer technischen Integration führen, wie das bei Kerberos der Fall ist, sondern nur einen Workaround bieten.

Single Sign-On-Herausforderungen werden zudem von Unternehmen immer mehr auch über Portale adressiert, wobei die Portal-Anwendungen mit dem Portal integriert werden. Die Authentifizierung erfolgt am Portal, dem die einzelnen Anwendungen vertrauen und von dem sie auch Informationen über die Benutzer erhalten.

End-to-End-Security

Neben der Zielsetzung des Single Sign-Ons spielt Kerberos aus einem zweiten Grund eine zunehmend wichtige Rolle: Kerberos ist ein hervorragend geeigneter Mechanismus, um Endto-End-Security zu erreichen. Der Begriff der End-to-End-Security bezeichnet Ansätze, bei denen ein Benutzer über die gesamte Verarbeitung hinweg in seiner Identität erkannt wird. Das wird am besten an konkreten Beispielen klar.

Viele Anwendungen arbeiten heute mit einem mehrschichtigen Modell. Browser greifen über den Webserver auf einen Anwendungsserver zu, der wiederum eine Datenbank nutzt. Bei n-Tier-Anwendungen ist Kerberos besonders interessant, beispielsweise wenn mehrere bestehende Systeme zur Abbildung eines Geschäftsprozesses integriert und in einem Portal zur Verfügung gestellt werden.

Heute werden diese Anwendungen häufig so realisiert, dass der Benutzer sich beim Zugriff über den Browser authentifizieren muss. Diese Authentifizierung kann beispielsweise über den Webserver erfolgen und wird von diesem gegebenenfalls auch noch an den Anwendungsserver weitergereicht. Dort ist der Benutzer nun bekannt. Der Anwendungsserver greift nun auf die Datenbank zu, um Daten für diesen Benutzer anzufordern. Die häufigste Lösung dafür ist, dass der Anwendungsserver dazu ein generisches Konto verwendet, das ihm volle Zugriffsberechtigungen zumindest für die benötigte Datenbank gibt. Durch die entsprechende Gestaltung von Abfragen und die Verarbeitung der Abfrageergebnisse schränkt die Anwendung anschließend ein, welche Informationen der Benutzer sehen darf.

Dieses Konzept hat den gravierenden Nachteil, dass die Anwendungssicherheit letztlich im Code der auf dem Anwendungsserver laufenden Anwendung versteckt wird. Dort müssen oft auch noch Kennwörter für die Datenbank gespeichert werden. Änderungen der Sicherheit sind nur durch Anpassungen des Quellcodes möglich. Außerdem lässt sich von außen kaum nachvollziehen, welcher Benutzer tatsächlich welche Zugriffsberechtigungen auf Informationen hat.

Mit dem Ansatz der End-to-End-Security kann das geändert werden, beispielsweise durch Nutzung von Kerberos. Der Benutzer authentifiziert sich auch hier und erhält ein Service Ticket für den Zugriff auf einen Dienst. Das Ticket und der Dienst sind so konfiguriert, dass eine Delegation erfolgen kann. In diesem Fall wird auf die Datenbank also in der Form zugegriffen, dass sich der Anwendungsserver anstelle des Benutzers authentifiziert – aber mit dessen Identität. Der Vorteil ist, dass er genau auf die Informationen zugreifen kann, die für den Benutzer freigegeben sind.

Das macht im Übrigen auch die Realisierung von Anwendungen einfacher, weil dort keine Sicherheitslogik realisiert werden muss. Der Nachteil ist, dass dafür wesentlich genauere Zugriffsberechtigungen auf allen Ebenen erforderlich werden. Man kann nicht mehr nur den Zugriff auf die Datenbank erlauben, sondern muss genau festlegen, wer wie darauf zugreifen darf. Außerdem muss die Datenbank die gleichen Benutzer wie beispielsweise der Anwendungsserver kennen. Diese Integration gibt es beispielsweise zwischen den Windows-Servern und dem Microsoft SQL Server. In anderen Konstellationen kann der administrative Aufwand dafür aber erheblich sein. Kerberos bietet durch seine Architektur eine umfassende Unterstützung für die End-to-End-Security. Dabei spielen zwei Aspekte eine zentrale Rolle:

• Mit den Service Tickets wird die enge Einbindung von Anwendungen unterstützt.

• Durch die Delegationsfunktionen kann eine Anwendung im Kontext eines Benutzers agieren, also mit genau den Berechtigungen zugreifen, die dieser hat.

Diese beiden Fähigkeiten machen Kerberos inzwischen zu einem zunehmend beachteten Mechanismus, dessen aktive Nutzung auch in heterogenen Umgebungen – also mit der Integration verschiedener Systemumgebungen und mit der Anpassung von Anwendungen für die Nutzung von Kerberos – immer mehr geschätzt wird. Verschiedene Aspekte der Herausforderungen, die sich bei der Nutzung von Kerberos sowohl innerhalb der Windows-Welt als auch im heterogenen Umfeld stellen, werden in den folgenden Artikeln näher betrachtet.

Das Thema der End-to-End-Security ist dabei keineswegs nur ein Entwicklerthema. Einerseits setzt es natürlich Anwendungen voraus, die beispielsweise Kerberos-Tickets verwenden können, X.509-Zertifikate akzeptieren oder bei denen die Federation-Standards genutzt werden können. Dahinter stehen aber immer auch administrative Herausforderungen. Das beginnt bei der Vergabe von differenzierten Berechtigungen auf allen Ebenen und geht bis hin zu einem anwendungsübergreifenden Benutzermanagement. Solche Ansätze müssen daher im Zusammenspiel von Anwendungsentwicklern und Systemadministratoren entwickelt werden, weil keiner der Bereiche alleine eine Lösung schaffen kann.

Kerberos ist, wie in dem Artikel deutlich wurde, ein Ansatz, dieses Ziel zu erreichen. Es gibt aber auch andere Lösungsmöglichkeiten. Welche davon am besten geeignet ist, hängt primär von den vorhandenen Anwendungen und der IT-Infrastruktur ab. Innerhalb des Netzwerks ist Kerberos aber ein interessanter Mechanismus, der zu Recht in den letzten Monaten wieder in den Blickpunkt gerückt ist, nachdem sich nach dem Release von Windows 2000 die Erwartungen zunächst nicht erfüllt hatten.