test

Sun Enterprise Authentication Mechanism Handbuch

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