test

Sun Enterprise Authentication Mechanism 1.0.1 Handbuch

Kapitel 1 Einführung zu SEAM

In diesem Kapitel erhalten Sie eine Einführung zu SEAM.

Was ist SEAM?

SEAM (Sun Enterprise Authentication Mechanism, Sun Enterprise-Authentisierungsmechanismus) bietet eine Client/Server-Architektur, die eine strikte Benutzerauthentisierung, Datenintigrität und Vertraulichkeit bereitstellt, um sichere Transaktionen zwischen Netzwerken zu ermöglichen. Authentisierung garantiert, dass die Identität des Senders und Empfängers einer Netzwerktransaktion echt ist. SEAM kann auch die Gültigkeit von wechselseitig übertragenen Daten verifizieren (Integrität) und diese für die Übertragung verschlüsseln (Vertraulichkeit). Mit SEAM können Sie sich auf anderen Systemen anmelden, Befehle ausführen, Daten austauschen und Daten gesichert übertragen. Zusätzlich bietet SEAM Dienste für die Autorisierung, mit denen Systemverwalter den Zugriff auf Dienste und Systeme beschränken können. Als SEAM-Benutzer können Sie außerdem den Zugriff anderer Personen auf Ihren Zugang steuern.

Bei SEAM handelt es sich um ein System mit einmaliger Anmeldung, weshalb Sie von SEAM nur einmal pro Sitzung authentisiert werden müssen, damit anschließend automatisch alle folgenden Transaktionen während der Sitzung gesichert sind. Nachdem Sie von SEAM authentisiert wurden, müssen Sie sich nicht bei jeder Verwendung eines SEAM-basierenden Befehls, wie z. B. ftp oder rsh, oder bei jedem Zugriff auf ein NFS-Dateisystem, neu authentisieren. Das bedeutet, dass Sie Ihr Passwort nicht bei jeder Verwendung dieser Dienste über das Netzwerk senden müssen, wo es abgefangen werden könnte.

SEAM basiert auf dem Netzwerk-Authentisierungsprotokoll von Kerberos V5, das am Massachusetts Institute of Technology (MIT) entwickelt wurde. Benutzern von Kerberos V5 sollte SEAM daher sehr bekannt vorkommen. Da Kerberos V5 de facto einen Industriestandard für Netzwerksicherheit darstellt, fördert SEAM die Interoperabilität mit anderen Systemen. Mit anderen Worten, da SEAM mit Systemen arbeitet, die Kerberos V5 verwenden, ermöglicht es gesicherte Transaktionen sogar über heterogene Netzwerke. Außerdem stellt SEAM die Authentisierung und Sicherheit sowohl zwischen Domains als auch innerhalb einer einzelnen Domain bereit.

Hinweis -

Da SEAM auf Kerberos V5 basiert und für die Interoperabilität mit diesem ausgelegt ist, verwendet diese Dokumentation die Begriffe "Kerberos" und "SEAM" mehr oder weniger gleichbedeutend -- zum Beispiel "Kerberos-Bereich" oder "SEAM-basiertes Dienstprogramm". (Ebenso werden auch "Kerberos" und "Kerberos V5" gleichbedeutend verwendet.) Die Dokumentation zeigt die Unterschiede dort auf, wo es erforderlich ist.

SEAM bietet Ihnen Flexibilität bei der Ausführung von Solaris-Anwendungen. Sie können SEAM so konfigurieren, dass sowohl SEAM-basierte als auch nicht-SEAM-basierte Anforderungen für Netzwerkdienste, wie z. B. NFS-Service, telnet und ftp, möglich sind. Das bedeutet, dass aktuelle Solaris-Anwendungen auch funktionieren, wenn sie auf Systemen ausgeführt werden, auf denen SEAM nicht installiert ist. Sie können SEAM auch so konfigurieren, dass nur SEAM-basierte Netzwerkanforderungen zugelassen werden.

Zudem müssen sich Anwendungen nicht nur auf SEAM festlegen, falls andere Sicherheitsmechanismen entwickelt werden. Da SEAM für die Integration der Modularität in die allgemeine Programmierschnittstelle für den Sicherheits-Service (Generic Security Service API) entwickelt wurde, können Anwendungen, die GSS-API verwenden, den Sicherheitsmechanismus wählen, der ihren Anforderungen am ehesten entspricht.

Funktionsweise von SEAM

Im folgenden erhalten Sie einen allgemeinen Überblick über das SEAM-Authentisierungssystem. Eine eingehendere Beschreibung finden Sie unter "Funktionsweise des Authentisierungssystems".

Aus der Sicht des Benutzers bleibt SEAM weitestgehend unsichtbar, nachdem die SEAM-Sitzung gestartet wurde. Befehle wie rsh oder ftp funktionieren im Großen und Ganzen wie bisher. Die Initialisierung einer SEAM-Sitzung besteht häufig nur aus der Anmeldung und Eingabe eines Kerberos-Passworts.

Das SEAM-System dreht sich um das Konzept eines Tickets. Ein Ticket stellt einen Satz elektronischer Informationen dar, der als Identifikation für einen Benutzer oder einen Service, wie z. B. den NFS-Service, verwendet wird. So wie Ihr Führerschein Sie identifiziert und anzeigt, welche Fahrerlaubnis Sie besitzen, so identifiziert ein Ticket Sie und Ihre Zugriffsberechtigungen für das Netzwerk. Wenn Sie eine SEAM-basierte Transaktion durchführen - zum Beispiel bei der Ausführung eines rlogin für ein anderes System - senden Sie transparent eine Ticketanforderung an ein Key Distribution Center oder KDC, das auf eine Datenbank zugreift, um Ihre Identität zu authentisieren. Das KDC gibt ein Ticket zurück, das Ihnen die Berechtigung für den Zugriff auf das andere System gewährt. "Transparent" bedeutet, dass Sie ein Ticket nicht explizit anfordern müssen; dies erfolgt als Teil des Befehls rlogin. Da nur der authentisierte Client ein Ticket für einen bestimmten Service abrufen kann, ist es einem anderen Client nicht möglich, rlogin mit einer angenommenen Identität zu verwenden.

Den Tickets sind bestimmte Attribute zugeordnet. Ein Ticket kann beispielsweise das Attribut weiterreichbar (d. h., es kann auf einem anderen System ohne einen neuen Authentisierungsprozess verwendet werden) oder Nachdatiert (nicht vor einem bestimmten Zeitpunkt gültig) besitzen. Die Verwendung von Tickets - zum Beispiel, welche Benutzer welchen Tickettyp empfangen dürfen - wird über Richtlinien festgelegt, die bei der Installation oder Verwaltung von SEAM bestimmt werden.

Hinweis -

Die Begriffe Berechtigungsnachweis und Ticket treten häufiger auf. Im umfassenderen Kerberos-Umfeld werden Sie häufig gleichbedeutend verwendet. Ein Berechtigungsnachweis besteht technisch gesehen jedoch aus einem Ticket und dem Sitzungsschlüssel für diese Sitzung. Der Unterschied wird eingehender unter "Zugriff auf einen Service mit SEAM erhalten" erläutert.

Die folgenden Abschnitte erläutern kurz den SEAM-Authentisierungsprozess.

Anfangsauthentisierung: Ticket-granting Ticket

Die Kerberos-Authentisierung erfolgt in zwei Phasen: Eine Anfangsauthentisierung, die nachfolgende Authentisierungen zuläßt, sowie die nachfolgenden Authentisierungen selbst.

Abbildung 1-1 erläutert, wie die Anfangsauthentisierung durchgeführt wird:

Abbildung 1-1 Anfangsauthentisierung für SEAM-Sitzung

Graphic

  1. Ein Client (ein Benutzer oder ein Service wie NFS) startet eine SEAM-Sitzung, indem ein Ticket-granting Ticket (TGT) vom Key Distribution Center angefordert wird. Dieser Vorgang erfolgt häufig automatisch bei der Anmeldung.

    Ein Ticket-granting Ticket wird benötigt, um andere Tickets für bestimmte Services abzurufen. Sie können sich ein Ticket-granting Ticket ähnlich wie einen Reisepass vorstellen. Das Ticket-granting Ticket weist Sie wie ein Reisepass aus und ermöglicht es Ihnen, zahlreiche "Visa" zu erhalten -- wobei die "Visa" (Tickets) nicht für fremde Länder sondern für entfernte Systeme oder Netzwerkdienste gelten. Ticket-granting Tickets sowie die weiteren verschiedenen Tickets besitzen, wie auch Reisepässe und Visa, nur eine begrenzte Gültigkeit. Der Unterschied besteht darin, dass "Kerberos"-Befehle erkennen, dass Sie einen Reisepass besitzen, und dann die Visa für Sie abrufen -- Sie müssen die Transaktion nicht selbst durchführen.

  2. Das KDC erzeugt ein Ticket-granting Ticket und sendet es verschlüsselt an den Client zurück. Der Client entschlüsselt das Ticket-granting Ticket mit Hilfe seines Passworts.

  3. Nachdem der Client nun im Besitz eines Ticket-granting Tickets ist, kann er Tickets für alle Netzwerkoperationen, wie z. B. rlogin oder telnet anfordern, solange das Ticket-granting Ticket gültig ist. Die Gültigkeit beträgt normalerweise einige Stunden. Bei jeder eindeutigen Netzwerkoperation fordert der Client ein Ticket für diese Operation vom KDC an.

Nachfolgende Authentisierungen

Nachdem der Client die Anfangsauthentisierung erhalten hat, folgt jede einzelne Authentisierung einem Muster, wie in Abbildung 1-2 beschrieben:

Abbildung 1-2 Zugriff auf einen Service erhalten

Graphic

  1. Der Client fordert ein Ticket für einen bestimmten Service (z. B., um ein rlogin für ein anderes System durchzuführen) vom KDC an, wobei dem KDC sein "Ticket-granting Ticket" als Identitätsnachweis gesendet wird.

  2. Das KDC sendet das Ticket für den bestimmten Dienst an den Client.

    Nehmen wir zum Beispiel an, der Benutzer josef verwendet rlogin auf dem Server hamburg. Da seine Authentisierung bereits erfolgt ist (d. h., er verfügt bereits über das Ticket-granting Ticket), erhält er automatisch und transparent ein Ticket als Teil des Befehls rlogin. Dieses Ticket ermöglicht es ihm, ein rlogin beliebig oft für hamburg durchzuführen, bis das Ticket nicht mehr gültig ist. Wenn josef ein rlogin für das System hannover durchführen will, erhält er ein anderes Ticket, wie in Schritt 1 beschrieben.

  3. Der Client sendet das Ticket an den Server.

  4. Der Server gewährt den Zugriff durch den Client.

Wenn Sie sich diese Schritte betrachten, scheint es, dass der Server nie mit dem KDC kommuniziert. Dies ist jedoch nicht der Fall. Der Server registriert sich beim KDC auf dieselbe Weise wie der erste Client. Dieser Teil wurde der Einfachheit halber weggelassen.

SEAM-basierte Befehle

Wie lauten die SEAM-basierten (oder "Kerberized") Befehle, die Benutzer wie josef verwenden können? Folgende Befehle sind möglich:

Bei diesen Anwendungen handelt es sich um dieselben Anwendungen wie die gleichnamigen Solaris-Anwendungen, jedoch mit dem Unterschied, dass sie Kerberos-Hauptbenutzer zur Authentisierung von Transaktionen verwenden, und somit eine Kerberos-basierte Sicherheit bieten. Weitere Informationen zu Hauptbenutzern finden Sie in "Hauptbenutzer".

Eine eingehende Erläuterung der Befehle finden Sie unter "SEAM-Befehle".

Hauptbenutzer

In SEAM wird ein Client über den Hauptbenutzernamen identifiziert. Ein Hauptbenutzer stellt eine eindeutige Identität dar, der das KDC Tickets zuweisen kann. Bei einem Hauptbenutzer kann es sich um einen Benutzer wie josef oder einen Service wie nfs oder telnet handeln.

Der Hauptbenutzername wird laut Konvention in drei Teile unterteilt: Primär, Instanz und Bereich. Ein typischer SEAM-Hauptbenutzer wäre z. B. josef/admin@ENG.ACME.COM, wobei:

Im folgenden sehen Sie Beispiele für gültige Hauptbenutzernamen:

Bereiche

Ein Bereich stellt ein logisches Netzwerk dar, wie z. B. eine Domain, das eine Gruppe von Systemen unter demselben Master-KDC definiert (siehe unten). Abbildung 1-3 zeigt die möglichen Beziehungen zwischen Bereichen. Einige Bereiche sind hierarchisch angeordnet (ein Bereich stellt eine Obermenge eines anderen Bereichs dar). Andernfalls besitzen die Bereiche keine Hierarchie und die Zuordnung muss somit zwischen den beiden Bereichen definiert werden. Zu den Funktionen von SEAM zählt die Möglichkeit, die Authentisierung über Bereiche hinweg durchzuführen. Jeder Bereich muss nur über einen Hauptbenutzereintrag für den anderen Bereich in seinem KDC verfügen.

Abbildung 1-3 Bereiche

Graphic

Bereiche und Server

Jeder Bereich muss einen Server einbeziehen, der die Master-Kopie der Hauptbenutzer-Datenbank verwaltet. Dieser Server wird als Master-KDC-Server bezeichnet. Zusätzlich sollte jeder Bereich mindestens einen Slave-KDC-Server enthalten, der Kopien der Hauptbenutzer-Datenbank enthält. Sowohl die Master- als auch die Slave-KDC-Server erstellen Tickets zur Einrichtung der Authentisierung.

Der Bereich kann auch zwei zusätzliche Arten von SEAM-Servern einbeziehen. Der Anwendungs-Server für ein SEAM-Netzwerk ist ein Server, der den Zugriff auf Kerberos-Anwendungen bereitstellt (wie ftp, telnet und rsh). Bereiche können auch NFS-Server umfassen, die NFS-Services mit Hilfe der Kerberos-Authentisierung bereitstellen.

Abbildung 1-4 zeigt, was ein hypothetischer Bereich enthalten könnte.

Abbildung 1-4 Ein typischer Bereich

Graphic

Sicherheits-Services

SEAM stellt zusätzlich zur sicheren Authentisierung von Benutzern zwei weitere Sicherheits-Services bereit:

Momentan kann der Benutzer trotz der zahlreichen Kerberos-Anwendungen, die Bestandteil von SEAM sind, nur mit dem Befehl ftp den Sicherheits-Service zur Laufzeit ändern ("en passant"). Entwickler können ihre RPC-basierten Anwendungen entwerfen, um mit Hilfe der RPCSEC_GSS-Programmierschnittstelle einen Sicherheits-Service auszuwählen.

Versionen von SEAM

Teile dieses Produkts waren in drei unterschiedlichen Produktversionen enthalten. Die erste Version von SEAM war Bestandteil von Solaris Easy Access Server (SEAS), Version 3.0. Diese Version umfasste die gesamte Software, die für Erstellung, Ausführung und Verwaltung eines Kerberos-Bereichs für Solaris 2.6 und 7 benötigt wird. Dabei handelte es sich um SEAM 1.0. Dann war die SEAM-Client-Software Bestandteil von Solaris 8. Dies ermöglichte es Solaris 8-Clients, ein SEAM 1.0 KDC zu verwenden. Im vorliegenden Dokument wird SEAM 1.0.1 beschrieben, die Vollversion von SEAM 1.0. Sie ermöglicht das Erstellen und die Unterstützung von Kerberos-Bereichen, wenn Solaris 8 ausgeführt wird. Die Komponenten der einzelnen Versionen werden in den folgenden Abschnitten beschrieben.

Komponenten von SEAM 1.0

Wie auch die MIT-Distribution von Kerberos V5 umfasst SEAM folgende Komponenten:

Zusätzlich enthält SEAM die folgenden Komponenten:

SEAM-Komponenten in Solaris 8

Solaris 8 umfasste nur die für Clients relevanten Teile von SEAM. Deshalb war eine Reihe von Komponenten nicht enthalten. Systeme, auf denen Solaris 8 ausgeführt werden, können als SEAM-Clients eingesetzt werden, ohne dass eine eigene Installation von SEAM erforderlich ist. Wenn Sie diese Funktionalität nutzen möchten, müssen Sie ein KDC installieren. Dazu benötigen Sie entweder ein SEAS 3.0 oder ein Solaris 8 Admin Pack, die MIT-Distribution oder Windows2000. Die Client-Komponenten können nicht ohne ein konfiguriertes KDC für die Verteilung von Tickets benutzt werden. In dieser Version sind folgende Komponenten enthalten:

Komponenten von SEAM 1.0.1

SEAM 1.0.1 umfasst alle Bestandteile von SEAM 1.0, die nicht in Solaris 8 enthalten sind. Dazu gehören folgende Teile: