test

Sun Enterprise Authentication Mechanism Handbuch

Kapitel 1 Einführung zum SEAM

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

Was ist SEAM?

SEAM (Sun Enterprise Authentication Mechanism, Sun Enterprise-Authentisierungsmechanismus) stellt eine Client/Server-Architektur dar, die eine strikte Benutzerauthentisierung, Datenintigrität und Vertraulichkeit bereitstellt, um sichere Transaktionen zwischen Netzwerken zu bieten. Die Authentisierung garantiert, daß 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 authentisieren. Das bedeutet, daß Sie Ihr Paßwort 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 einen de facto 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 dort Unterschiede auf, wo es erforderlich ist.

SEAM bietet Ihnen Flexibilität bei der Ausführung von Solaris-Anwendungen. Sie können SEAM konfigurieren, damit sowohl SEAM-basierte und nicht SEAM-basierte Anforderungen für Netzwerkdienste, wie z. B. der NFS-Service, telnet und ftp möglich sind. Das bedeutet, daß 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, daß 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 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 Authentisierunssystems".

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 auf die übliche Weise. Die Initialisierung einer SEAM-Sitzung besteht häufig nur aus der Anmeldung und Eingabe eines Kerberos-Paßworts.

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, daß 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 Attributweiterreichbar (d. h., es kann auf einem anderen System ohne einen neuen Authentisierungsprozeß 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-Authentisierungsprozeß.

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 Reisepaß vorstellen. Das Ticket-granting Ticket weist Sie wie ein Reisepaß aus und ermöglicht es Ihnen, zahlreiche "Visas" zu erhalten -- wobei die "Visas" (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 Visas, nur eine begrenzte Gültigkeit. Der Unterschied besteht darin, daß "Kerberos"-Befehle erkennen, daß Sie einen Reisepaß besitzen und dann die Visas für Sie abrufen -- Sie müssen die Transaktion nicht selbst durchführen.

    Eine weitere Vergleichsmöglichkeit zum Ticket-granting Ticket stellt ein drei Tage gültiger Skipaß dar, der für vier unterschiedliche Skigebiete gilt. Sie können den Skipaß in jedem der vier Gebiete vorzeigen (bis er abläuft) und erhalten dann ein Lift-Ticket für dieses Gebiet. Nachdem Sie über das Lift-Ticket verfügen, können Sie im gesamten Gebiet Skilaufen. Wenn Sie am nächsten Tag in ein anderes Gebiet fahren, zeigen Sie Ihren Paß wieder vor und erhalten ein weiteres Lift-Ticket für das neue Gebiet. Der Unterschied besteht darin, daß die auf SEAM-basierenden Befehle erkennen, daß Sie einen Wochenend-Skipaß besitzen und dann die Lift-Tickets für Sie abrufen, damit Sie die Transaktion nicht selbst durchführen müssen.

  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 Paßworts.

  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 Beweis seiner Identität gesendet wird.

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

    Nehmen Sie 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. Außerdem muß er kein neues Ticket abrufen, um den Befehl telnet für hamburg durchzuführen - das ursprüngliche Ticket enthält die Identität von hamburg. 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, daß 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 einfachheitshalber weggelassen.

SEAM-basierte Befehle

Folgende Befehle gehören zu den SEAM-basierten (oder "Kerberos") Befehlen, die Benutzer wie josef verwenden können:

Diese Anwendungen stimmen mit den Solaris-Anwendungen gleichen Namens überein, mit der Ausnahme, daß sie Kerberos-Hauptbenutzer für die Authentisierung von Transaktionen verwenden und somit die Sicherheit auf Kerberos basiert. (Weitere Informationen über Hauptbenutzer finden Sie unter "Hauptbenutzer".)

Diese Befehle werden eingehender unter "SEAM-Befehle" erläutert.

Hauptbenutzer

Ein Client wird in SEAM über seinen Hauptbenutzer 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 dar (siehe unten). Abbildung 1-3 erläutert, welche Beziehungen zwischen Bereichen bestehen können. Einige Bereiche sind hierarchisch angeordnet (ein Bereich stellt eine Obermenge eines anderen Bereichs dar). Andernfalls besitzen die Bereiche keine Hierarchie und die Zuordnung muß 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 muß nur über einen Hauptbenutzereintrag für den anderen Bereich in seinem KDC verfügen.

Abbildung 1-3 Bereiche

Graphic

Bereiche und Server

Jeder Bereich muß 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 Typische Bereiche

Graphic

Sicherheits-Services

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

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

SEAM-Komponenten

Wie auch die MIT-Distribution von Kerberos V5 umfaßt SEAM folgende Komponenten:

Zusätzlich enthält SEAM die folgenden Komponenten: