DE69331424T2

DE69331424T2 - Verfahren und Einrichtung zur Berechtigung einer gleichrangigen Verbindung

Info

Publication number: DE69331424T2
Application number: DE69331424T
Authority: DE
Inventors: Brent Allen Carlson; Frederic Lawrence Huss; Nancy Marie Schmucki; Richard Elmer Zelenski
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1992-09-11
Filing date: 1993-09-03
Publication date: 2002-09-26
Anticipated expiration: 2013-09-04
Also published as: EP0588415B1; JPH06223014A; US5506961A; EP0588415A1; DE69331424D1; US5542046A; JP2519390B2

Description

Die vorliegende Erfindung bezieht sich im allgemeinen auf den Bereich der Datenverarbeitung und im besonderen auf die Berechtigung einer gleichrangigen Verbindung.
Da früher Computersysteme nur einfache Aufgaben ausführen konnten, war es nicht nötig, dass sie mehr als eine Eingabe/Ausgabe-Einheit (E/A-Einheit) enthielten. Aus diesem Grund enthielten Computersysteme wie beispielsweise EDVAC aus dem Jahr 1948 nur eine einzige Eingabe/Ausgabe-Einheit. die Eingabe/Ausgabe-Einheit war lediglich der Mechanismus, der vom Computersystem verwendet wurde, um mit der Außenwelt zu kommunizieren. Da diese frühen Computersysteme nur eine relativ kleine Datenmenge erforderten, konnte die Eingabe/Ausgabe-Einheit von der zentralen Verarbeitungseinheit (CPU) selbst gesteuert werden. Mit fortschreitender Entwicklung erforderten die von Computersystemen ausgeführten komplexen Aufgaben Zugriff auf immer mehr Informationen. Die direkte Steuerung der Eingabe/Ausgabe-Einheit durch die CPU war nicht länger möglich.
Im Jahr 1959 stellte die UNIVAC Corporation ihr Computersystem LARC vor. Das Computersystem LARC umfasste einen Eingabe/Ausgabe-Controller (IOC), der für sich genommen bereits ein echter Computer war. Der IOC wurde verwendet, um den Informationsfluss zu und von der Außenwelt zu bewältigen, wodurch die Arbeitsbelastung für die CPU verringert werden konnte. Während der IOC bis zu acht Eingabe/Ausgabe-Kanäle steuerte, enthalten heutige Computersysteme normalerweise für jeden Eingabe/Ausgabe-Kanal einen eigenen Eingabe/Ausgabe- Controller. Diese Eingabe/Ausgabe-Controller werden Eingabe/Ausgabe-Prozessoren (IOPs) genannt. Ähnlich wie der IOC des Computersystems LARC sind IOPs eigenständige Computersysteme. Jeder IOP ist für die Bewältigung des Informationsflusses zwischen einem bestimmten externen Gerät (d. h. der "Außenwelt") und dem Computersystem verantwortlich.
Die weithin verbreitete Verwendung von IOPs hat die Gesamtleistung heutiger Computersysteme wesentlich verbessert. Computersysteme können nun mit einer Vielzahl externer Geräte kommunizieren, ohne die CPU über Maßen in Anspruch zu nehmen. Beispiele für Geräte, die sich über IOPs anschließen lassen, sind Bildschirme, magnetische Speichergeräte, optische Speichergeräte, programmierbare Workstations und andere Computersysteme. Für das Computersystem stellt jedes dieser externen Geräte eine Ressource dar, die zur Ausführung einer bestimmten Aufgabe verwendet werden kann. In vielen Fällen lässt sich die jeweilige Aufgabe mit externen Geräten ohne nennenswerte Beteiligung der CPU ausführen. Dadurch kann natürlich die Leistungsanforderung an die CPU in hohem Maße reduziert werden.
Moderne Multimedia-Anwendungen erfordern normalerweise sehr viele Zugriffe auf Audio- und Video-Informationen und zeigen somit besonders deutlich den möglichen Leistungsvorteil von IOPs. Die Datenmengen, die erforderlich sind, um einem Benutzer Audio- und Video-Informationen zur Verfügung zu stellen, sind enorm. Somit sind theoretisch immense Leistungseinsparungen möglich, wenn eine Multimedia-Anwendung, die mit einem IOP verbunden ist, die Haupt-CPU umgehen und direkt auf Informationen eines anderen IOP zugreifen kann. Bei dieser sehr eigenständigen Vorgehensweise besteht jedoch das Problem der Sicherung von Informationen und Ressourcen. Wenn man willkürlich allen externen Geräten eine Verbindung gestattet, wird die unberechtigte Nutzung von Systemressourcen zu einem wahren Problem. Ohne irgendeine Form von Sicherheit können Benutzer der verschiedensten externen Geräte versuchen, Zugriff auf persönliche oder vertrauliche Daten zu bekommen. Das Problem verschärft sich, wenn man bedenkt, dass das Computersystem, die verschiedenen IOPs sowie die angeschlossenen externen Geräte im Besitz von unterschiedlichen Parteien sind oder von verschiedenen Parteien hergestellt wurden. Im schlimmsten Fall können feindselige IOPs in das Computersystem eingeschleust werden, die der unberechtigten Nutzung von Systemressourcen (beispielsweise Datendiebstahl) Vorschub leisten.
Lösungen zu diesem Problem bringen immer einen bestimmten Anteil von CPU-Beteiligung mit ins Spiel. Somit wird zwischen Effizienz und Sicherheit ein Kompromiss geschlossen. Ein Computersystem mit mehr Sicherheit ist tendenziell weniger effizient, während ein Computersystem mit hoher Effizienz nicht so sicher ist. Diese Beeinträchtigung ist auf die Tatsache zurückzuführen, dass Computersysteme mit hoher Sicherheit ein Mittel (d. h. Berechtigungsmittel) enthalten müssen, um den Zugriff auf Systemressourcen zu gestatten oder zu verweigern. Zwar erhöhen Berechtigungsmittel in der Tat die Sicherheit, doch entstehen auch aufwendige und kostspielige zusätzliche Leistungsanforderungen, die die Effizienz des Gesamtsystems beeinträchtigen. Aus diesem Grund versuchen die Entwickler von Computersystemen stets einen Kompromiss aus Effizienz und Sicherheit zu erreichen.
Ein Modell zur Lösung des Sicherheitsproblems ist ein Berechtigungsmodell namens Kerberos. Kerberos ist eine gemeinsame Entwicklung der Digital Equipment Corporation, der International Business Machines Corporation (IBM) und dem Massachusetts Institute of Technology (MIT) zur Nutzung auf einem MIT-weiten Computernetzwerk.
Kerberos verwendet ein System von Nachrichten und Tasten, um das Problem der Sicherheit zu lösen. Um Informationen von einem Server zu erhalten, muss ein Client zuerst die Berechtigung von einem Kerberos-Server einholen. Bei diesem Schritt kommen zahlreiche verschlüsselte Nachrichten ins Spiel, die vom Kerberos-Server an die Client- und Server- Geräte sowie vom Client an den Server gesendet werden. Nach Abschluss dieser Übertragungen ist das Client-Gerät in der Lage, eine Verbindung zum Server-Gerät herzustellen.
Zwar ist Kerberos eine anschauliche Lösung für ein Sicherheitsproblem, doch wurde es nicht darauf ausgelegt, das Problem feindseliger IOPs zu lösen. Darüber hinaus ist das Kerberos-Authentifizierungsmodell in vielerlei Hinsicht mit Fehlern behaftet. Eines der Probleme im Kerberos-Modell ist seine Komplexität. Jedes Gerät, das an der Authentifizierungsprozedur teilnehmen möchte, muss sich zuerst beim entsprechenden Kerberos-Server anmelden. Dazu benötigt das betreffende Gerät Informationen über die Ressourcen, die von bestimmten Kerberos-Servern gesteuert werden, worauf das Gerät sich beim entsprechenden Kerberos-Server anmelden kann. Die Anmeldung selbst ist komplex, weil jeder Kerberos-Server jedem Gerät eine eigene Verschlüsselung zuordnen muss. Kommen mehrere Kerberos-Server ins Spiel, muss jedes Gerät wissen, welche Verschlüsselung für welche Ressourcen verwendet werden müssen.
Die Komplexität des Kerberos-Modells wird durch die Tatsache, dass das Modell eine Verschlüsselung benötigt, noch erhöht. Das Kerberos-Modell würde ohne sein ausgefeiltes Verschlüsselungssystem nicht funktionieren. Jedes Gerät muss eine gemeinsame geheime Verschlüsselungskryptographie unterstützen und wissen, wie die Verschlüsselungen im Kerberos-Protokoll verwendet werden. Wenn ein Kerberos-Client eine Berechtigungsanforderung empfängt, muss er wissen, welche Verschlüsselung dem Client zugeordnet werden muss, welche Verschlüsselung zum Server gehört und welche Verschlüsselung zur Kommunikation zwischen den beiden Geräten verwendet werden kann. Wenn der Client diese Informationen vom Kerberos-Server empfängt, muss er wissen, dass er seinen Schlüssel verwenden muss, um die ihm zugeschickte Nachricht zu entschlüsseln, dass er die vom Kerberos-Server an das Server-Gerät gesendete Nachricht nicht entschlüsseln kann, und dass er die neue Verschlüsselung verwenden muss, um seine Antwort für das Server-Gerät zu verschlüsseln. Wenn das Server-Gerät schließlich die Nachricht vom Client-Gerät erhält, muss es wissen, dass es die gemeinsame geheime Verschlüsselung verwenden muss, um auf die neue Verschlüsselung zuzugreifen, und dass es die neue Verschlüsselung verwenden muss, um auf die Informationen vom Client-Gerät zuzugreifen. Diese Komplexität multipliziert sich, wenn man bedenkt, dass jedes Gerät an mehreren Verbindungen beteiligt sein kann.
Ein weiteres Problem des Kerberosmodells und der eigenständigen Vorgehensweise im allgemeinen ist, dass den Client-Geräten nicht genügend Ressourceninformationen zur Verfügung stehen. Um sich anzumelden, muss der Client nicht nur wissen, wo sich die Systemressourcen befinden, sondern muss auch ausdrücklich dem Kerberosserver mitteilen, wie der jeweilige Server heißt, mit dem er eine Kommunikation aufbauen möchte. Das Kerberosmodell sieht keine Berechtigung vor, bei der ein Gerät auf Informationen zugreift. In anderen Worten, ein Client kann nicht einfach sagen: "Ich möchte Zugriff auf die Information X". Ein Kerberosserver würde eine solche Anforderung zurückweisen, weil sie die notwendige Serveradresse nicht enthält.
Es ist ein Hauptziel der vorliegenden Erfindung, ein verbessertes Verfahren und eine verbesserte Vorrichtung zur Übertragung von Daten zwischen den Bestandteilen eines Computersystems bereitzustellen.
Es ist ein weiteres Ziel der vorliegenden Erfindung, ein verbessertes Verfahren und eine verbesserte Vorrichtung zur Berechtigung von Verbindungen zwischen den IOPs eines Computersystems bereitzustellen.
Es ist ferner ein Ziel der vorliegenden Erfindung, ein verbessertes Verfahren und eine verbesserte Vorrichtung zur Berechtigung von Verbindungen zwischen gleichen Geräten bereitzustellen.
Es ist ferner ein Ziel der vorliegenden Erfindung, ein verbessertes Verfahren und eine verbesserte Vorrichtung zur Berechtigung von Verbindungen zwischen einem Server und mehreren Clients bereitzustellen.
Es ist ferner ein Ziel der vorliegenden Erfindung, ein verbessertes Verfahren und eine verbesserte Vorrichtung zur Berechtigung von Verbindungen zwischen mehreren Servern und einem einzigen Client bereitzustellen.
Es ist ferner ein Ziel der vorliegenden Erfindung, ein verbessertes Verfahren und eine verbesserte Vorrichtung zur Berechtigung von Verbindungen zwischen mehreren Servern und mehreren Clients bereitzustellen.
Es ist ferner ein Ziel der vorliegenden Erfindung, ein verbessertes Verfahren und eine verbesserte Vorrichtung zur Vermeidung unberechtigter Zugriffe auf Systemressourcen durch feindselige IOPs bereitzustellen.
Diese und weitere Ziele werden durch die Vorrichtung gemäß Definition in Anspruch 1 und das entsprechende Verfahren gemäß Beschreibung in Anspruch 12 erreicht.
EP-A-0 281 224 beschreibt ein System zur Verteilung von Verschlüsselungen, das dem Verteilungsmechanismus für Berechtigungstokens gemäß Beschreibung in diesem Dokument ähnelt, wobei Verschlüsselungen verwendet werden, um Nachrichten, die über bereits bestehende Verbindungen gesendet werden, zu verschlüsseln und entschlüsseln. Die vorliegende Erfindung hat den Aufbau berechtigter Verbindungen in einem Computersystem zum Ziel.
EP-A-0 15 348 beschreibt ein Verfahren zum Aufbau von Verbindungen zwischen zwei Computern, wobei der anfordernde Computer an den angeforderten Computer einen Initialisierungscode sendet, worauf an den anfordernden Computer eine Bestätigungsmeldung zurück gesendet wird.
Der Entwurf des Berechtigungsverfahrens, das von der beschriebenen Einrichtung zur Berechtigung einer gleichrangigen Verbindung verwendet wird, sieht drei verschiedene Einheiten vor: einen Systemberechtigungsmechanismus, einen Client- Verbindungsmanager und einen Server-Verbindungsmanager. Der Systemberechtigungsmechanismus befindet sich in der Haupt-CPU, während sich der Client-Verbindungsmanager und der Server- Verbindungsmanager auf individuellen IOPs befinden.
Um die Informationen einzuholen, die von einem Benutzer und/oder einem Anwendungsprogramm angefordert wurden, gibt der Client-Verbindungsmanager an den Systemberechtigungsmechanismus eine Anforderung ab. Da die Client-Anwendung möglicherweise den Speicherort der gewünschten Informationen nicht kennt, kann die Anforderung die Adresse eines Server-Geräts enthalten (d. h. der Client- Verbindungsmanager liefert nicht die Adresse eines Server- Geräts, wenn dem Client-Verbindungsmanager der Speicherort der gewünschten Informationen unbekannt ist). Wenn der Systemberechtigungsmechanismus die Anforderung empfängt, prüft er erst nach, ob das Client-Gerät auch genau das Gerät ist, dass es zu sein vorgibt. Anschließend ermittelt der Systemberechtigungsmechanismus das richtige Server-Gerät, indem er entweder die Adresse, die der Client- Verbindungsmanager enthält, oder die in der Anforderung enthaltenen Informationen verwendet. Kommt der Systemberechtigungsmechanismus zu dem Ergebnis, dass das Client-Gerät Zugriff auf Informationen auf dem betreffenden Server-Gerät erhalten sollte, sendet er einen Token an das Server-Gerät und eine Kopie des gleichen Tokens an das Client- Gerät. Je nach Sicherheitsrelevanz kann der Token verschlüsselt sein. Es ist ebenfalls möglich, dass sich die gewünschten Informationen auf mehr als einem Server-Gerät befinden oder dass mehr als ein Client-Gerät die Informationen wünscht. Der Systemberechtigungsmechanismus kann mehrere Gerätesituationen bewältigen, indem er mehrere Tokens und Tokenkopien versendet.
Beim Empfang der Tokenkopie vom Systemberechtigungsmechanismus packt der Client-Verbindungsmanager die Tokenkopie in eine Nachricht, die er an das Server-Gerät sendet. Wenn der Server- Verbindungsmanager die Nachricht vom Client-Gerät empfängt, vergleicht er die Tokenkopie mit dem Token, den er vom Systemberechtigungsmechanismus erhalten hat. Stimmen diese Tokens überein, antwortet der Server-Verbindungsmanager dem Client-Gerät, und die Verbindung ist aufgebaut. Stimmen diese Tokens nicht überein, benachrichtigt der Server- Verbindungsmanager den Systemberechtigungsmechanismus, dass der Versuch, eine Verbindung aufzubauen, gescheitert ist. Danach wird das Client-Gerät darüber informiert.

Kurze Beschreibung der Zeichnungen:

Fig. 1 zeigt das Computersystem der vorliegenden Erfindung.
Fig. 2 zeigt die IOPs und die Verbindungsmanager der vorliegenden Erfindung.
Fig. 3 zeigt ein übersichtliches Funktionsdiagramm des Nachrichtenflusses zwischen dem Systemberechtigungsmechanismus und den Client- und Server-IOPs der vorliegenden Erfindung.
Fig. 4 zeigt Blockdiagramme der Anforderungsnachricht sowie die Berechtigungsnachricht und ihre Antwort gemäß einem bevorzugten Ausführungsbeispiel.
Fig. 5 zeigt Blockdiagramme der Nachrichten Offen und Antwort Offen gemäß einem bevorzugten Ausführungsbeispiel.
Fig. 6 zeigt Blockdiagramme des Versuchs zum Öffnen, des unberechtigten Versuchs zum Öffnen, des Befehls Token Rückgängig und der Antwortnachricht Geöffnet gemäß dem bevorzugten Ausführungsbeispiel.
Fig. 7 zeigt ein Blockdiagramm mit dem Format des Tokens gemäß dem bevorzugten Ausführungsbeispiel.
Fig. 8 zeigt ein Logikflussdiagramm des Systemberechtigungsmechanismus der vorliegenden Erfindung.
Fig. 9 zeigt ein Logikflussdiagramm des Server-IOP- Verbindungsmanagers der vorliegenden Erfindung.
Fig. 10 zeigt ein Logikflussdiagramm des Client-IOP- Verbindungsmanagers der vorliegenden Erfindung.
Fig. 1 zeigt ein Blockdiagramm des Computersystems der vorliegenden Erfindung. Das Computersystem des bevorzugten Ausführungsbeispiels ist ein IBM AS/400-Computersystem mittlerer Leistung. Es kann jedoch jedes beliebige Computersystem verwendet werden. Fig. 1 zeigt eine Explosionsansicht des Computersystems 100. Das Computersystem 100 umfasst die zentrale Verarbeitungseinheit (CPU) 105, die mit dem Primärspeicher 110 und dem System-Ein-und-Ausgabe-Bus 115 verbunden ist. Obwohl das in Fig. 1 abgebildete System nur eine einzige zentrale Verarbeitungseinheit (CPU) und nur einen einzigen System-Ein-und-Ausgabe-Bus enthält, ist dennoch zu berücksichtigen, dass das Prinzip der vorliegenden Erfindung sich ebenso gut auf Computersysteme mit mehreren zentralen Verarbeitungseinheiten (CPUs) und mehreren System- Ein-und-Ausgabe-Bussen anwenden lässt; und obwohl der System- Ein-und-Ausgabe-Bus des bevorzugten Ausführungsbeispiels ein typischer hartverdrahteter Multidrop-Bus ist, kann jedes Verbindungsmittel, das eine Kommunikation in beide Richtungen ermöglicht, verwendet werden.
Mit dem E/A-Systembus 115 sind die IOPs 120 verbunden. Zwar sind in Fig. 1 sechs IOPs und vier externe Geräte dargestellt, doch sei darauf hingewiesen, dass sich das Prinzip der vorliegenden Erfindung gleichermaßen auf jede andere Anzahl an externen Geräten bezieht, die an jede beliebige Anzahl an IOPs angeschlossen sind. Jeder der IOPs 120 ist so ausgelegt, dass er mit dem Bus 115 und dem externen Gerät, für das er verantwortlich ist, kommunizieren kann. Die in den IOPs des bevorzugten Ausführungsbeispiels (IOPs 120) verwendeten Prozessoren sind Mikrocomputer des Typs Motorola 68020, aber auch andere Mikrocomputer, beispielsweise vom Typ Intel 960, sind einsetzbar. Die Systemkonsole 125 ist über einen der IOPs 120 mit dem Bus 115 verbunden. Die Systemkonsole 125 ermöglicht es Systemadministratoren, mit dem Computersystem 100 zu kommunizieren, normalerweise über eine nicht-programmierbare Workstation. Auf ähnliche Weise sind der magnetische Speicher 130, der optische Speicher 135 und die programmierbare Workstation 140 jeweils über einen der IOPs 120 an den Bus 115 angeschlossen.
Die Sekundärspeicher 130 und 135 (der magnetische Speicher 130 und der optische Speicher 135) werden vom Computersystem 100 als Großspeicher für Daten und Programme verwendet. Die programmierbare Workstation 140 ermöglicht es Benutzern und Entwicklern, mit dem Computersystem 100 zu kommunizieren.
Der Primärspeicher 110 enthält den Systemberechtigungsmechanismus 112 und das Betriebssystem 114. Wie aus der Darstellung hervorgeht, ist der Systemberechtigungsmechanismus 112 im Primärspeicher 110 gespeichert. Es ist jedoch zu beachten, dass zwar normalerweise der Systemberechtigungsmechanismus 112 in den Primärspeicher geladen wird, um ausgeführt zu werden, er jedoch auch im magnetischen Speicher 130 oder im optischen Speicher 135 gespeichert sein kann.
Fig. 2 zeigt eine Explosionsansicht zweier der IOPs 120. Wie aus der Darstellung hervorgeht, werden die IOPs 200 und 250 als Schnittstellen zwischen dem I/O-Bus 115 und den Geräten 230 und 260 verwendet. Wenn wir uns auf den IOP 200 konzentrieren, sieht man in Fig. 2, dass die CPU 210, die Busschnittstelle 205 und der Primärspeicher 215 sowie die Geräteschnittstelle 220 alle über den Bus 225 miteinander verbunden sind. Im Primärspeicher 215 befindet sich der IOP- Verbindungsmanager 217.
In vielen Fällen sind die Busschnittstelle 205, die CPU 210, der Primärspeicher 215 und der Bus 225 in jedem der IOPs 220 die gleichen, jedoch sind der IOP-Verbindungsmanager 217 und die Geräteschnittstelle 220 normalerweise geräteabhängig. In anderen Worten, der IOP-Verbindungsmanager 217 und die Geräteschnittstelle 220 können sich je nach Gerät 230 unterscheiden. Wenn beispielsweise das Gerät 230 ein magnetischer Speicher ist, handelt es sich normalerweise beim IOP-Verbindungsmanager 217 um einen Server-Verbindungsmanager, und die Geräteschnittstelle 220 umfasst normalerweise Eingangs-/Ausgangs-Hardware, die dem magnetischen Speicher angemessen ist. Handelt es sich im Gegensatz dazu beim Gerät 230 um eine programmierbare Workstation (PWS), dann ist der IOP-Verbindungsmanager 217 ein Client-Verbindungsmanager, und die Geräteschnittstelle 220 enthält entsprechend Eingangs-/ Ausgangs-Hardware, die der programmierbaren Workstation (PWS) angemessen ist.
Fig. 3 zeigt ein funktionales Flussdiagramm der Kommunikation zwischen der Systemberechtigungsstation 112 und dem Server- Verbindungsmanager 300 sowie dem Client-Verbindungsmanager 350. Zwei verschiedene Arten logischer Verbindungen sind in Fig. 3 dargestellt. Die Diensteverbindungen 320, 370 und 385 werden verwendet, um verbindungsbezogene Informationen weiter zu leiten, während die Datenverbindung 390 für die Datenübertragung verwendet wird. Zwar erscheinen in den Abbildungen diese Verbindungen als logische Verbindungen, doch ist zu beachten, dass diese Verbindungen physikalisch gesehen auf dem I/O-Bus 115 stattfinden. Im bevorzugten Ausführungsbeispiel wird das Protokoll mit dem Namen IBM Inter-process Communication Facility (IPCF) verwendet, um diese logischen Verbindungen herzustellen. Natürlich lässt sich auch jedes beliebige andere Protokoll verwenden, sofern es in der Lage ist, logische Verbindungen zu erzeugen. Nähere Informationen zum IPCF-Protokoll siehe US-Patent 4,649,473 an Hammer et al.
Die Namen und Speicherstellen aller IOPs werden der Systemberechtigungsstation 112 bei der Initialisierung des Computersystems 100 mitgeteilt. Entsprechend werden die Busadresse und der Name des Systemberechtigungsmechanismus 112 jedem der IOPs mitgeteilt. Eine Berechtigung ist zum ersten Mal erforderlich, wenn eine Anwendung, die auf dem Client 380 läuft, Zugriff auf Ressourcen benötigt, die sich auf einem anderen Gerät befinden. Der Client-Verbindungsmanager 350 beginnt den Berechtigungsprozess, indem er eine Anforderungsnachricht 360 über die Diensteverbindung 370 an den Systemberechtigungsmechanismus 112 sendet. Die Anforderungsnachricht 360 kann anzeigen, dass eine Verbindung zu einem bestimmten Server-IOP oder dass lediglich Zugriff auf eine bestimmte Information gewünscht wird.
Der Systemberechtigungsmechanismus 112 reagiert auf die Anforderungsnachricht 360, indem er eine Nachricht 322 mit der Bezeichnung Peer-to-Peer-Authorization (nachfolgend PTPA- Nachricht) über die Diensteverbindung 320 an den Server- Verbindungsmanager 300 sendet. Das Format der PTPA-Nachricht 322 ist in Fig. 4 dargestellt. Zwar werden die Felder und das Format dieser Nachricht in der Beschreibung zu den Fig. 8 bis 10 ausführlicher beschrieben, doch verdient der Server- Token 440 in diesem Zusammenhang Berücksichtigung. Der Server- Token 440 wird in einer späteren Phase des Berechtigungsprozesses verwendet, um zu bestimmen, ob der Server-Verbindungsmanager 300 mit einer offenen Anforderung von einem Client-Verbindungsmanager übereinstimmen soll. Ebenfalls ist zu beachten, dass der Server-Verbindungsmanager 300 nur Tokens akzeptiert, die vom Systemberechtigungsmechanismus 112 bereitgestellt werden.
Nach Empfang der PTPA-Nachricht 322 verwendet der Server- Verbindungsmanager 300 die Diensteverbindung 320, um dem Systemberechtigungsmechanismus 112 mit der Nachricht 324 (Authorization Response) AR zu antworten. Wenn mit der Nachricht 324 (Authorization Response) AR alles in Ordnung ist, verwendet der Systemberechtigungsmechanismus 112 die Diensteverbindung 370, um die Nachricht Open-Peer-to-Peer- System-to-IOP (nachfolgend die OPTPSTI-Nachricht) 374 an den Client-Verbindungsmanager 350 zu senden. Das Format der OPTPSTI-Nachricht 374 ist in Fig. 5 dargestellt. Zwar werden die Felder und das Format dieser Nachricht in der Beschreibung zu den Fig. 8 bis 10 ausführlicher beschrieben, doch verdient der Server-Copy-Token 525 in diesem Zusammenhang Berücksichtigung. Der Server-Copy-Token 525 wird vom Client- Verbindungsmanager 350 verwendet, um seine Ressourcenanforderung beim Server-Verbindungsmanager 300 zu validieren. Der Client-Verbindungsmanager 350 verpackt den Server-Copy-Token 525 in die Nachricht Open-Peer-to-Peer-IOPto-IOP (nachfolgend die OPTPITI-Nachricht) 375 und sendet die Nachricht über die Diensteverbindung 385 an den Server- Verbindungsmanager 300. (Das Format der Nachricht OPTPITI 374 ist in Fig. 6 dargestellt.)
Nach Empfang der Nachricht OPTPITI 375, vergleicht der Client- Verbindungsmanager 300 den Server-Copy-Token 615 mit dem Server-Token 440. Wenn die Token übereinstimmen, sendet der Server-Verbindungsmanager 300 die Antwortnachricht Open-Peerto-Peer-IOPto-IOP-Response (nachfolgend die OPTPITIR- Nachricht) 325 über die Diensteverbindung 385, um dem Client- Verbindungsmanager 350 mitzuteilen, dass die Zugriffsberechtigung erteilt wird. Die Datenverbindung wird daraufhin über die Datenverbindung 390 erzeugt.
Wenn die Tokens nicht übereinstimmen, informiert der Server- Verbindungsmanager 300 die Systemberechtigung 112 über den unberechtigten Zugriffsversuch, indem er über die Diensteverbindung 320 die Nachricht Unauthorized Open Attempt (nachfolgend die Nachricht UOA) 310 absendet. Nach dem Absenden dieser Nachricht sendet der Server-Verbindungsmanager 300 die Nachricht OPTPITIR 325 über die Diensteverbindung 385, um dem Client-Verbindungsmanager 350 mitzuteilen, dass die Zugriffsberechtigung verweigert wird.
Wenn der Systemberechtigungsmechanismus 112 die Nachricht UOA empfängt, hat er die Aufgabe, eine geeignete Maßnahme zu ergreifen. Die geeignete Maßnahme kann von "keine Maßnahme ergreifen" bis zum Senden einer Nachricht Cancel Token (nachfolgend die Nachricht CT) an den Server- Verbindungsmanager 350 reichen. Die Nachricht CT ist ein Befehl, der den Server-Verbindungsmanagern mitteilt, dass sie vom betreffenden Token keine Zugriffsversuche akzeptieren sollen.
Beim Empfang der Nachricht OPTPITIR 325 wird der Client- Verbindungsmanager 350 aufgefordert, den Systemberechtigungsmechanismus 112 über das Ergebnis des Zugriffsversuchs zu informieren. Dazu sendet der Client- Verbindungsmanager 350 die Antwortnachricht Open-Peer-to-Peer- System-to-IOP-Response (nachfolgend die OPTPSTIR-Nachricht) 360 über die Diensteverbindung 370 an den Systemberechtigungsmechanismus 112.
Die Fig. 4 bis 6 zeigen die Formate, die für die Nachrichten des bevorzugten Ausführungsbeispiels verwendet werden. Diese Formate werden ausführlich in Verbindung mit der nachfolgenden Beschreibung der Fig. 8 bis 10 beschrieben.
Fig. 8 zeigt ein Flussdiagramm der Schritte, die der Systemberechtigungsmechanismus 112 unternimmt, um Peer-to- Peer-Verbindungen zu ermöglichen. Zum Zweck einer gut verständlichen Erläuterung gehen wir von der Annahme aus, dass es sich beim Client-Gerät 380 von Fig. 3 um ein PWS handelt, auf dem eine Multimedia-Anwendung ausgeführt wird, und dass das Server-Gerät 340 von Fig. 3 ein optischer Speicher ist. Wir nehmen weiter an, dass das optische Speichergerät 340 Multimedia-Informationen enthält, die die auf dem PWS 380 laufende Multimedia-Anwendung benötigt, und dass der Client- Verbindungsmanager 350 und der Server-Verbindungsmanager 300 in Fig. 3 auf den IOPs laufen, die zum PWS 380 bzw. zum optischen Speicher 340 gehören.
In Block 800 empfängt der Systemberechtigungsmechanismus 112 die Namen und Speicherorte aller IOPs des Computersystems 100 und speichert sie in einer geeigneten Tabelle. Wie oben bereits angeführt wurde, geschieht dies als Bestandteil der Initialisierung des Computersystems 100.
Nach der Initialisierung in Block 800 wartet der Systemberechtigungsmechanismus 112 auf die Berechtigungsanforderung 806. Der Systemberechtigungsmechanismus 112 kehrt immer dann in diesen Wartestatus zurück, wenn die Verarbeitung einer Berechtigungsanforderung abgeschlossen ist. Die Blöcke 805 und 810 stellen zwei verschiedene Arten von Berechtigungsanforderungen dar. Die externe Berechtigungsanforderung 810 stellt eine Anforderung dar, die in einem Gerät außerhalb des Computersystems 100 abgesendet wurde. Im vorliegenden Fall wurde die externe Berechtigungsanforderung vom Multimedia-PWS 380 abgeschickt. Die interne Berechtigungsanforderung 805 stellt eine Anforderung dar, die vom System selbst initiiert wurde. Letztere Anforderung wird in Verbindung mit der Beschreibung des ersten alternativen Ausführungsbeispiels beschrieben.
Wenn die auf dem PWS 380 laufende Multimedia-Anwendung Mutlimedia-Informationen benötigt, fordert sie den Client- Verbindungsmanager 350 auf, an den Systemberechtigungsmechanismus 112 eine Anforderungsnachricht zu senden.
Fig. 4 zeigt das Format dieser Anforderungsnachricht. Dieses Format wird beispielsweise auch in der Anforderungsnachricht 360 verwendet. Das Format 400 der Anforderungsnachricht umfasst das Feld 410 zur Angabe der Client-Ressourcenkennung, das Feld 415 zur Angabe der Server-Ressourcenkennung, das Feld 420 zur Angabe der Informationskennung sowie das Feld 425 zur Angabe der Zugriffsrechte. Das Feld 410 zur Angabe der Client- Ressourcenkennung wird zur Angabe des Client-Geräts verwendet, das die Informationen benötigt. In unserem Multimedia-Beispiel wäre in diesem Feld die Identität des PWS 380 enthalten. Das Feld 415 zur Angabe der Server-Ressourcenkennung ist ein optionales Feld, das eine Angabe des Speicherorts für das Server-Gerät enthält. Dieses Feld könnte in der Nachricht enthalten sein, wenn der Speicherort der angeforderten Informationen dem Client-Gerät bekannt ist. In unserem Beispiel würde man dieses Feld ausfüllen, wenn die Multimedia- Anwendung wüsste, dass die von ihr benötigten Informationen im optischen Speicher 340 gespeichert sind. Das Feld 420 zur Angabe der Informationskennung wird zur Identifikation der Informationen verwendet oder wenn der Speicherort dieser Informationen dem Anforderer unbekannt sind. Beispielsweise weiß möglicherweise die Multimedia-Anwendung, die auf dem PWS 380 läuft, welche Informationen sie benötigt, sie weiß aber möglicherweise nicht, wo sich diese Informationen befinden. In diesem Fall verwendet der Systemberechtigungsmechanismus 112 das Feld 420 zur Angabe der Informationskennung, um festzustellen, wo sich die gewünschten Informationen befinden. Im bevorzugten Ausführungsbeispiel wird eine Tabelle (nicht dargestellt) verwendet, die bestimmte Informationskennungen mit dem Speicherort der Informationen verknüpft. Natürlich kann aber auch jedes beliebige andere Mittel zur Herstellung einer Verknüpfung zwischen einer Anforderung bestimmter Informationen und dem Speicherort dieser Informationen verwendet werden. Das Feld 425 zur Angabe der Zugriffsrechte gibt an, welchen Zugriffstyp das Client-Gerät benötigt. Beispielsweise könnte die auf dem PWS 380 laufende Multimedia- Anwendung eine Berechtigung für das Beschreiben und Lesen eines bestimmten Speichers wünschen.
Der Systemberechtigungsmechanismus 112 empfängt diese Anforderung im funktionalen Block 810. Auf der Grundlage der Anforderungsart sowie allgemeiner Systemfaktoren ermittelt der Systemberechtigungsmechanismus 112 den Tokentyp, die Anzahl der abgesendeten Token und die Verbreitung der Tokentypen 815. Zu den allgemeinen Systemfaktoren können die aktuelle Nutzung der Systemressourcen, der Speicherort der Informationen oder aber jeder beliebige andere Faktor gehören, der einen Einfluss darauf hat, wie die Anforderung verarbeitet wird. Die Blöcke 820, 825 und 830 zeigen die drei verschiedenen Tokentypen, die verwendet werden können. Wenn der Systemberechtigungsmechanismus 112 den Tokentyp für einmalige Verwendung wählt (in der Darstellung ist dies die Auswahl 830), werden der an den Server ausgesendete Token oder die an die Server ausgesendeten Token genau einmal verwendet und anschließend zerstört. In unserem Multimedia-Beispiel entscheidet der Systemberechtigungsmechanismus 112, diesen Tokentyp dann zu verwenden, wenn auf der Grundlage der Anforderung vom Client-Verbindungsmanager 350 er feststellt, dass alle Informationen mit einem einzigen Zugriff eingeholt werden könnten. In anderen Worten, der Systemberechtigungsmechanismus 112 kann feststellen, dass die Quantität oder Art der angeforderten Informationen dergestalt sind, dass diese Informationen ohne mehrere Zugriffsanforderungen eingeholt werden können.
Um dieses Beispiel noch weiter zu führen, nehmen wir an, dass sich ein Teil der angeforderten Informationen im optischen Speicher 340 befindet, der Rest jedoch in einem anderen optischen Speicher (nicht dargestellt). Im Multimedia-Beispiel kann das der Fall sein, wenn die Video-Informationen im optischen Speicher 340 und die Audio-Informationen in einem anderen optischen Speicher (nicht dargestellt) gespeichert sind. Wenn das der Fall ist, sendet der Systemberechtigungsmechanismus 112 Tokens zur einmaligen Verwendung an den Server-Verbindungsmanager 300 sowie an den Server-Verbindungsmanager, der zum zweiten optischen Speicher gehört (nicht dargestellt). Die Art und Weise, wie diese Tokens zu einem späteren Zeitpunkt von den betreffenden Client-Verbindungsmanager(n) verwendet werden, wird in den nachfolgenden Abschnitten beschrieben.
Wiederverwendbare Tokens (in der Darstellung ist das die Auswahl 825) werden eingesetzt, wenn der Systemberechtigungsmechanismus 112 feststellt, dass ein ständiger Zugriff auf Informationen erforderlich ist. In unserem Beispiel könnte der Systemberechtigungsmechanismus 112 anhand der vom Client-Verbindungsmanager 350 gelieferten Informationen ermitteln, dass die Multimedia-Anwendung, die auf dem PWS 380 läuft, einen ständigen Zugriff auf die Informationen benötigt, die im optischen Speicher 340 gespeichert sind.
Um auch dieses Beispiel noch weiter zu führen, nehmen wir an, dass ein ständiger Zugriff auf Informationen, die in einem zusätzlichen optischen Speicher (nicht dargestellt) gespeichert sind, ebenfalls benötigt wird. Wenn dies der Fall wäre, würde der Systemberechtigungsmechanismus 112 wiederverwendbare Tokens an den Server-Verbindungsmanager 300 sowie an den Server-Verbindungsmanager des zweiten optischen Speichers (nicht dargestellt) senden.
Die Entscheidung, ob ein Token zur einmaligen Verwendung oder ein wiederverwendbarer Token verwendet werden soll, hängt auch davon ab, welchen Kompromiss zwischen Sicherheit und Leistung man einzugehen bereit ist. Der Systemberechtigungsmechanismus 112 kann beispielsweise entscheiden, einen Token zur einmaligen Verwendung einem wiederverwendbaren Token vorzuziehen, wenn die gewünschten Informationen vertraulich sind. Entsprechend kann der Systemberechtigungsmechanismus 112 entscheiden, einen wiederverwendbaren Token einem Token zur einmaligen Verwendung vorzuziehen, wenn dabei die Systemleistung im Vordergrund steht.
Der letzte Tokentyp, der generische Token (dargestellt als Auswahl 820), wird verwendet, um einen freien Zugriff auf die Daten eines bestimmten Server-Geräts zu ermöglichen. In unserem Multimedia-Beispiel kann dies der Fall sein, wenn der Systemberechtigungsmechanismus 112 feststellt, dass ein anderes Client-Gerät als der PWS 380 möglicherweise die im optischen Speichergerät 340 gespeicherten Daten benötigt und dass dieser Zugriff frei gewährt werden sollte. Auch hier könnte der Systemberechtigungsmechanismus 112 feststellen, dass diese Bedingungen für mehr als nur das optische Speichergerät 340 bestehen, und mehrere generische Token aussenden.
Wie oben kann auch hier der Systemberechtigungsmechanismus 112 entscheiden, einen generischen Token anderen Tokenarten aus Systemleistungserwägungen heraus vorzuziehen.
Die Verschlüsselungsoption (dargestellt als Entscheidungsblock 835) ist im bevorzugten Ausführungsbeispiel enthalten, um bei Bedarf eine zusätzliche Sicherheit zu bieten. Es ist jedoch wichtig zu beachten, dass das Prinzip der vorliegenden Erfindung zur Durchführung der Berechtigungsfunktion nicht von der Verschlüsselungsfähigkeit abhängig ist. Wie aus der Darstellung in Fig. 8 hervorgeht, ist die Verschlüsselungsfunktion nicht sinnvoll, wenn generische Tokens gewählt wurden.
Sobald die angeforderten Informationen gefunden und die Token oder Tokens eines bestimmten Typs erzeugt (und ggf. verschlüsselt) wurden, bündelt der Systemberechtigungsmechanismus 112 diese(n) zu einer PTPA- Meldung, die er an den jeweiligen Server-Verbindungsmanager sendet. Fig. 4 zeigt das genaue Format der PTPA-Meldung. Das Feld 430 enthält die PTPA-Meldungstypanzeige. Das Feld 435 wird im IPCF-Protokoll verwendet, um zu ermitteln, für welche Einheit die Berechtigung gewünscht wird. Das Client- Zugriffsfeld 450 wird verwendet, um dem empfangenden Server- Verbindungsmanager (hier dem Server-Verbindungsmanager 300) anzugeben, welche Zugriffsrechte vom Client angefordert wurden. Das Feld 440 enthält den eigentlichen Token selbst, während das Feld 445 eine Angabe des Tokentyps (d. h. Einmalverwendung, Mehrfachverwendung oder generisch) enthält. Fig. 7 zeigt das im bevorzugten Ausführungsbeispiel der vorliegenden Erfindung verwendete Tokenformat. Das Tokenformat 700 umfasst die Client-IOP-Adresse 705, die Client-IOP- Ressource 710, die Uhrzeit 715 und einen Zufallswert 720. Die Client-IOP-Adresse 705 ist ein Feld, das den Speicherort der Client-IOP angibt. In unserem Multimedia-Beispiel würde dieses Feld die Adresse des IOPs enthalten, auf dem der Client- Verbindungsmanager 350 ausgeführt wird. Die Client-IOP- Ressource 710 ist ein Feld, das die Kennung der Ressource enthält, die Informationen anfordert. In unserem Beispiel würde dieses Feld die Kennung von PWS 380 enthalten. Das Feld für die Uhrzeit 715 und das Feld für einen Zufallswert 720 werden verwendet, um Eindeutigkeit zu erzeugen und um eine Verschlüsselung zu ermöglichen, falls eine zusätzliche Sicherheit gewünscht wird.
In unserem Beispiel würde der Token an den Server- Verbindungsmanager 300 sowie möglicherweise an andere 845 gesendet werden. Sobald dies abgeschlossen ist, stellt der Systemberechtigungsmechanismus 112 fest, ob bedingt durch die Art der Anforderung und/oder bedingt durch allgemeine Systemfaktoren die Verwendung eines anderen Tokentyps 850 erforderlich ist. Dieses Szenario lässt sich am besten beschreiben, indem man unser erweitertes Multimedia-Beispiel erneut betrachtet. Zusätzlich zur Annahme, dass sich die erforderlichen Informationen auf mehr als einem Server-Gerät befinden, nehmen wir an, dass die Zugriffsbedürfnisse der Server-Geräte unterschiedlich sind. Die Multimedia-Anwendung kann beispielsweise einen kontinuierlichen Zugriff auf die Bilddaten benötigen, die im optischen Speichergerät 340 gespeichert sind, jedoch nur einen Einmal-Zugriff auf die Audio-Informationen, die im anderen optischen Speichergerät (nicht dargestellt) gespeichert sind. Wenn das der Fall wäre, würde der Systemberechtigungsmechanismus 112 entscheiden, einen wiederverwendbaren Token an den Server- Verbindungsmanager 300 und einen Einmal-Token an den Server- Verbindungsmanager (nicht dargestellt), der mit dem anderen optischen Speichergerät (nicht dargestellt) verbunden ist, zu senden.
Sobald alle PTPA-Nachrichten gesendet sind, beginnt der Systemberechtigungsmechanismus 112 mit der Verarbeitung der AR-Nachrichten, die er empfangen hat (855). Das Format der AR- Nachricht wird in Fig. 4 gezeigt. Das AR-Format 470 umfasst das Nachrichtentypenfeld 455 und das Statusfeld 460. Das Statusfeld 460 wird vom Systemberechtigungsmechanismus 112 verwendet, um festzustellen, ob eine Fortsetzung gewünscht wird. Eine Fortsetzung wäre beispielsweise nicht angemessen, wenn das Statusfeld 460 anzeigen würde, dass die optische Speichereinrichtung 340 derzeit nicht verfügbar ist.
Angenommen, alles ist in Ordnung, macht der Systemberechtigungsmechanismus 112 weiter und setzt an Schritt 860 die notwendige(n) OPTPSTI-Nachricht(en) zusammen. Das Format der OPTPSTI-Nachricht wird in Fig. 5 dargestellt. Das OPTPSTI-Nachrichtenformat 500 umfasst das Nachrichten- Typenfeld 505, das Client-Ressourcenkennungsfeld 510, das Server-Ressourcenkennungsfeld 515, das Server-Routenfeld 520, den Server-Copy-Token 525 und das Client-Zugriffsfeld 530. Das Client-Ressourcenkennungsfeld 510 gibt das Client-Gerät an, für das die Berechtigung bestimmt ist. In unserem Fall ging die Anforderung von PWS 380 aus, und daher ist sie das Client- Gerät, das die Berechtigung für den Zugriff auf Informationen erhalten hat, die auf der optischen Speichereinrichtung 340 gespeichert sind. Das Server-Routenfeld 520 enthält Positionsangaben, die vom Client-Verbindungsmanager 350 verwendet werden, um die Verbindung zwischen PWS 380 und der optischen Speichereinrichtung 340 aufzubauen. Das Server-Copy- Tokenfeld 525 enthält die Kopie des Tokens, der nötig ist, um Zugang zu den auf der optischen Speichereinrichtung 340 gespeicherten Informationen zu erhalten. Das Client- Zugriffsfeld 530 schließlich wird verwendet, um den Client- Verbindungsmanager 350 über die gewährten Zugriffsrechte zu informieren.
Sobald die entsprechenden Nachrichten erstellt wurden, werden sie an den Client-Verbindungsmanager 350 gesendet (Block 865). Zu diesem Zeitpunkt wartet der Systemberechtigungsmechanismus 112 auf eine Antwort vom Client-Verbindungsmanager 350 (Block 870). Fig. 5 zeigt das Format der OPTPSTIR-Nachricht. Das OPTPSTIR-Nachrichtenformat 550 umfasst das Nachrichtentypenfeld 555, das Client-Statusfeld 560 und das Server-Statusfeld 565. Das Statusfeld in jeder Nachricht wird verwendet, um den Status des betreffenden Geräts anzuzeigen. Die Statusfelder werden in Block 880 von Fig. 8 verarbeitet. Wenn die berechtigte Verbindung stattgefunden hat, geben die Statusfelder das an. (Die Art und Weise, wie Verbindungen aufgebaut werden, ist in der Beschreibung der Fig. 9-10 festgelegt.) Wenn eine Verbindung nicht stattgefunden hat, veranlassen die Felder den Systemberechtigungsmechanismus 112, eine Abhilfemaßnahme zu ergreifen (nicht dargestellt). Diese Abhilfemaßnahme kann von "keine Maßnahme" bis zur Rückgängigmachung der entsprechenden Tokens reichen.
Die Art und Weise, wie der Systemberechtigungsmechanismus 112 die UOA-Nachricht verarbeitet (dargestellt in Block 890), wird in Verbindung mit der Beschreibung von Fig. 9 dargelegt.
Fig. 9 zeigt den Prozessfluss für den Server- Verbindungsmanager 300. In der Beschreibung von Fig. 8, Block 845, haben wir gesehen, dass die PTPA-Meldungen, vom Systemberechtigungsmechanismus 112 an den Server- Verbindungsmanager 300 gesendet wurden. (Eine ausführliche Beschreibung des Formats der PTPA-Nachricht ist in der Beschreibung von Fig. 8 enthalten.) Der Server- Verbindungsmanager 300 empfängt diese Nachrichten im funktionalen Block 900 und verarbeitet diese anschließend in Block 970. In Block 975 stellt der Server-Verbindungsmanager 300 fest, ob es möglich ist, die mit den Nachrichten verbundene Anfrage zu bearbeiten. Dies ist beispielsweise dann nicht möglich, wenn das optische Speichergerät 340 zum Zeitpunkt der Anfrage nicht funktionsfähig war oder wenn das IOP selbst nicht genügend Ressourcen zur Verfügung hatte, um die Anfrage zu verarbeiten. Wenn dies der Fall ist, gibt der Server-Verbindungsmanager 300 dies in seiner AR-Nachricht an den Systemberechtigungsmechanismus 112 an (dargestellt durch die Blöcke 975 und 942) und schließt ab in 932. (Eine ausführliche Beschreibung des Formats der AR-Nachricht ist in der Beschreibung von Fig. 8 enthalten.) Wenn der Systemberechtigungsmechanismus 112 weiter machen soll, wird die Verschlüsselungsoption aktiviert (dargestellt durch die Blöcke 980 und 952), und der Token wird gespeichert, 985. Der Server-Verbindungsmanager 300 sendet darauf hin die entsprechende AR-Nachricht zurück an den Systemberechtigungsmechanismus 112 (dargestellt durch den Block 990) und schließt ab in 962.
Wir betrachten nun Fig. 10. (Die übrigen Blöcke von Fig. 9 beziehen sich auf eine Verarbeitung von Nachrichten des Client-Verbindungsmanagers 350 und des Systemberechtigungsmechanismus 112. Diese Blöcke sind besser verständlich, sobald der Ursprung dieser Nachrichten beschrieben wurde.) Fig. 10 zeigt, dass die OPTPSTI-Nachricht vom Systemberechtigungsmechanismus 112 in Block 1000 vom Client-Verbindungsmanager 350 empfangen wird. Der Client- Verbindungsmanager 350 antwortet auf die OPTPSTI-Nachricht vom Systemberechtigungsmechanismus 112, indem er eine OPTPITI- Nachricht erstellt und an den Server-Verbindungsmanager 300 sendet. Fig. 6 zeigt das Format der OPTPITI-Nachricht. Die OPTPITI-Nachricht 600 umfasst den Nachrichtentyp 605, die Server-Ressourcenkennung 610 und den Server-Copy-Token 615. Das Server-Ressourcenkennungsfeld 610 wird verwendet, um die Ressource anzugeben, die die angeforderten Informationen enthält. Das Server-Copy-Tokenfeld 615 enthält den Copy-Token 615, der vom Systemberechtigungsmechanismus 112 empfangen wurde.
Wir betrachten nun Fig. 9. Die OPTPITI-Nachricht wird in Block 320 vom Server-Verbindungsmanager 300 empfangen. Nach Verwendung der optionalen Verschlüsselung (dargestellt durch die Blöcke 945 und 960) stellt der Server-Verbindungsmanager 300 fest, ob der Copy-Token, den er in der OPTPITI-Nachricht erhalten hat, gültig ist, 950. Die Validierung erfolgt dadurch, dass der Copy-Token mit dem in der PTPA-Nachricht enthaltenen Token verglichen wird. Wenn der Token gültig ist, fragt der Server-Verbindungsmanager 300 als nächstes, ob er mit der Verarbeitung der Anfrage 963 weiter machen soll. Wie auch oben prüft der Verbindungsmanager 300, ob der IOP und das Gerät genügend Ressourcen besitzen, um die Anfrage des Tokens zu verarbeiten. Nachdem die Gültigkeit des Tokens und die Verfügbarkeit der Ressourcen sichergestellt wurden, bestimmt der Server-Verbindungsmanager 300, ob der Token ein Einmal- Token ist, 965. Wenn der Token ein Einmal-Token ist, wird er zerstört, 992, indem er aus dem IOP-Speicher gelöscht wird. Nach dieser Entscheidung antwortet der Server- Verbindungsmanager 300 auf den Client-Verbindungsmanager 350 mit einer OPTPITIR-Nachricht, 982. Fig. 6 zeigt das Format der OPTPITIR-Nachricht. Das OPTPITIR-Nachrichtenformat 650 umfasst das Nachrichtentypenfeld 620, das Übertragungsbeschränkungsfeld 625, das Statusfeld 630 und das Client- Zugriffsfeld 633. Das Übertragungsbeschränkungsfeld 625 enthält Informationen wie beispielsweise die maximale Größe der Nachrichtenpakete sowie die maximale Übertragungsgeschwindigkeit. Das Statusfeld 630 wird verwendet, um den Client-Verbindungsmanager 350 über das Ergebnis des Zugriffsversuchs zu informieren. Wie auch oben wird das Client-Zugriffsfeld 633 verwendet, um den Client- Verbindungsmanager 350 über die gewährten Zugriffsrechte zu informieren.
Wenn der Server-Verbindungsmanager 300 feststellt, dass der Copy-Token ungültig ist, sendet er eine UOA-Nachricht an den Systemberechtigungsmechanismus 112 (dargestellt durch Block 955), bevor er dem Client-Verbindungsmanager 350 antwortet.
Das Format der UOA-Nachricht wird in Fig. 6 dargestellt. Das UOA-Nachrichtenformat 655 umfasst das Nachrichten-Typenfeld 635, das Client-Ressourcenkennungsfeld 640, das Client- Routenfeld 643, den Token, der im Zugriffsversuch, 645, verwendet wurde (d. h. den Token, der im Server-Copy-Tokenfeld 615 der betreffenden OPTPITI-Nachricht enthalten ist), sowie das Uhrzeitfeld 660. Das Client-Ressourcenkennungsfeld gibt das Client-Gerät und den Client-IOP an, die für die Zurückweisung des Zugriffsversuchs verantwortlich sind. In unserem Multimedia-Beispiel wären dies PWS 380 und der dazugehörige IOP (dargestellt durch das Client-Routenfeld 643). Diese Nachricht wird daraufhin in Block 890 von Fig. 8 vom Systemberechtigungsmechanismus 112 verarbeitet. Wie bereits angeführt wurde, muss der Systemberechtigungsmechanismus 112 entscheiden, welche Abhilfemaßnahme erforderlich ist. Wenn der Systemberechtigungsmechanismus 112 entscheidet, den gültigen Token rückgängig zu machen, sendet er eine CT-Nachricht (nicht dargestellt) an den Server- Verbindungsmanager 300. Fig. 6 zeigt das Format der CT- Nachricht. Das CT-Nachrichtenformat 675 umfasst das Nachrichtentypenfeld 665, den rückgängig zu machenden Token 670 und die Client-Route, der zu dem rückgängig zu machenden Token gehört. Diese Nachricht wird vom Server- Verbindungsmanager 300 in Block 925 von Fig. 9 empfangen. Der Server-Verbindungsmanager 300 antwortet auf die CT-Nachricht, indem er den Token 930 für den angegebenen IOP zerstört. Der Server-Verbindungsmanager 300 beendet daraufhin die Verarbeitung, 940.
Zum Schluss betrachten wir Fig. 10. Der Client- Verbindungsmanager 350 empfängt die OPTPITIR-Nachricht vom Server-Verbindungsmanager 300 in Block 1015. Wenn das Statusfeld der OPTPITIR-Nachricht anzeigt, dass eine Verbindung gewährt wurde, initiiert der Client- Verbindungsmanager 350 die berechtigte Datenverbindung 1015 und sendet eine OPTPSTIR-Nachricht 1020 an den Systemberechtigungsmechanismus 112, um ihn darüber zu informieren. Wenn das Statusfeld der OPTPITIR-Nachricht anzeigt, dass eine Verbindung nicht gewährt wurde, muss der Client-Verbindungsmanager 350 dennoch eine OPTPSTIR-Nachricht verwenden, um den Systemberechtigungsmechanismus 112 über den gescheiterten Zugriffsversuch zu informieren. Obwohl diese Maßnahme vom Client-IOP verlangt wird, kann ein feindlicher Client-IOP, der die Anforderungen nicht erfüllt, nicht unerkannt bleiben. Wie oben bereits angeführt wurde, ist der Server-Verbindungsmanager auch dafür verantwortlich, den Systemberechtigungsmechanismus 112 zu benachrichtigen (siehe Block 955 von Fig. 9).
Im ersten alternativen Ausführungsbeispiel empfängt der Systemberechtigungsmechanismus 112 die Berechtigungsanforderung intern vom Computersystem 100 selbst, 805. Dies wäre der Fall, wenn eine Anwendung, die auf dem CPU 105 läuft, feststellte, dass die Geräte von zwei oder mehreren IOPs zusammenarbeiten müssten, um eine bestimmte Aufgabe zu erfüllen. Zu diesem Zeitpunkt würde das Berechtigungsverfahren fortgesetzt werden, wie oben bereits beschrieben wurde.
Im zweiten alternativen Ausführungsbeispiel wird das Prinzip der vorliegenden Erfindung auf ein Netzwerk mehrerer Computer angewandt. Es wird darauf hingewiesen, dass zwar das bevorzugte Ausführungsbeispiel das Prinzip der vorliegenden Erfindung anwendet, um Verbindungen zwischen den IOPs eines einzelnen Computersystems zu gewähren, das Prinzip der vorliegenden Erfindung aber auch in einer Netzwerkumgebung angewandt werden kann. In diesem alternativen Ausführungsbeispiel werden die IOPs 120 durch einen oder mehrere unabhängige Computer ersetzt, und der Bus 115 wird in einem oder mehreren physikalischen Netzwerkschnittstellen ersetzt. Beispiele für solche Schnittstellen sind: IEEE 802.5 (Token Ring), IEEE 802.4 (Token Bus), IEEE 802.3 (Ethernet), FDDI, X.25 und ISDN. Die Verfahren und die Vorrichtungen, die im primären und ersten alternativen Ausführungsbeispiel beschrieben werden, gelten gleichermaßen für dieses Ausführungsbeispiel.

Claims

1. Eine Vorrichtung zur Datenübertragung zwischen einer Client-Station (350) und einer Server-Station (300), wobei die genannte Vorrichtung eine Berechtigungsstation (112), eine Client-Station (350) und eine Server-Station (300) umfasst;

wobei die genannte Berechtigungsstation (112) folgendes umfasst:

ein Mittel für den Empfang einer Datenanforderung (360) von der genannten Client-Station (350);

ein Mittel zum Senden eines Berechtigungstokens (322) an die genannte Server-Station (300) in Verbindung mit der genannten Anforderung (360) von der genannten Client- Station (350); und

ein Mittel zum Senden einer Kopie (374) des genannten Berechtigungstokens (322) an die genannte Client-Station (350);

wobei die genannte Client-Station (350) folgendes umfasst:

ein Mittel zur Abgabe der genannten Datenanforderung (360) an die genannte Systemberechtigungsstation (112);

ein Mittel für den Empfang der genannten Kopie (374) des genannten Berechtigungstokens (322) von der genannten Berechtigungsstation (112) zusammen mit der genannten Anforderung (360);

ein Mittel zur Anforderung einer Verbindung zur genannten Server-Station (300), wobei die genannte Verbindung über einen Befehl (375) angefordert wird, der an die genannte Server-Station (300) gesendet wird, wobei der genannte Befehl (375) die genannte Kopie (374) des genannten Berechtigungstokens (322) umfasst; und

ein Mittel zum Aufbau der genannten Verbindung zur genannten Server-Station (300), nachdem die genannte Kopie (374) des genannten Berechtigungstokens (322) von einem Validierungsmittel der genannten Server-Station (300) validiert wurde; und

wobei die genannte Server-Station (300) folgendes umfasst:

ein Mittel für den Empfang des genannten Berechtigungstokens (322) von der genannten Berechtigungsstation (112) zusammen mit der genannten Anforderung (360);

ein Mittel für den Empfang der genannten Kopie (374) des genannten Berechtigungstokens (322) von der genannten Client-Station (350) als Bestandteil der genannten Nachricht (375), die den Befehl zum Aufbau der genannten Verbindung zwischen der genannten Server-Station (300) und der genannten Client-Station (350) enthält; und

ein Mittel zur Validierung der genannten Kopie (374) des genannten Berechtigungstokens (322), wobei die genannte Validierung durch Vergleich der genannten Kopie (374) des genannten Berechtigungstokens (322) mit dem genannten Berechtigungstoken (322) erfolgt, wobei die genannte Validierung erfolgreich ist, wenn die genannten Tokens (322, 374) übereinstimmen.

2. Eine Vorrichtung gemäß Anspruch 1, wobei die genannte Datenanforderung (360) eine Anforderung für den Zugriff auf Systemressourcen darstellt.

3. Eine Vorrichtung gemäß Anspruch 1 oder 2, wobei die genannte Client-Station (350) einen ersten IOP- Verbindungsmanager umfasst, der sich auf einem ersten IOP befindet.

4. Eine Vorrichtung gemäß Anspruch 1, 2 oder 3, wobei die genannte Server-Station (300) einen zweiten IOP- Verbindungsmanager umfasst, der sich auf einem zweiten IOP befindet.

5. Eine Vorrichtung gemäß jedem der obigen Ansprüche, wobei die genannten Berechtigungstokens (322) übertragen werden und die genannte Verbindung auf einem Bus (320, 370, 385) aufgebaut wird.

6. Eine Vorrichtung gemäß jedem der obigen Ansprüche, wobei das genannte Mittel zum Senden der Berechtigungstokens (322) mindestens eines der nachfolgend aufgeführten Mittel enthält:

ein Mittel zum Senden eines generischen Berechtigungstokens;

ein Mittel zum Senden eines wiederverwendbaren Berechtigungstokens;

ein Mittel zum Senden eines Einmal-Berechtigungstokens.

7. Eine Vorrichtung gemäß jedem der obigen Ansprüche, wobei das genannte Mittel für den Empfang der Berechtigungstokens (322) mindestens eines der nachfolgend aufgeführten Mittel enthält:

ein Mittel für den Empfang eines generischen Berechtigungstokens;

ein Mittel für den Empfang eines wiederverwendbaren Berechtigungstokens;

ein Mittel für den Empfang eines Einmal- Berechtigungstokens.

8. Eine Vorrichtung gemäß jedem der obigen Ansprüche, wobei das genannte Mittel für den Aufbau einer Verbindung mindestens eines der nachfolgend aufgeführten Mittel enthält:

ein Mittel zur Ausgabe des Ergebnisses des genannten Validierungsmittels an den genannten IOP- Verbindungsmanager (350) der Client-Station;

ein Mittel zur Ausgabe des Ergebnisses des genannten Validierungsmittels an die genannte Systemberechtigungsstation (112).

9. Eine Berechtigungsstation (112) zur Verwendung in der Vorrichtung gemäß jedem der obigen Ansprüche zur Datenübertragung zwischen einer Client-Station (350) und einer Server-Station (300), wobei die genannte Berechtigungsstation (112) folgendes umfasst:

ein Mittel zum Senden einer Kopie (374) des genannten Berechtigungstokens (322) an die genannte Client-Station (350).

10. Eine Client-Station (350) zur Verwendung in der Vorrichtung gemäß jedem der obigen Ansprüche zur Datenübertragung an eine Server-Station (300), wobei die genannte Client-Station (350) folgendes umfasst:

ein Mittel zur Ausgabe einer Datenanforderung (360) an eine Systemberechtigungsstation (112);

ein Mittel für den Empfang einer Kopie (374) eines Berechtigungstokens (322) von der genannten Berechtigungsstation (112) zusammen mit der genannten Anforderung (360);

ein Mittel zur Anforderung einer Verbindung zur genannten Server-Station (300), wobei diese Verbindung über einen Befehl (375) angefordert wird, der an die genannte Server- Station (300) gesendet wird, wobei der genannte Befehl (375) die genannte Kopie (374) des genannten Berechtigungstokens (322) umfasst; und

ein Mittel zum Aufbau der genannten Verbindung zur genannten Server-Station (300), nachdem die genannte Kopie (374) des genannten Berechtigungstokens (322) von einem Validierungsmittel der genannten Server-Station (300) validiert wurde.

11. Eine Server-Station (300) zur Verwendung in der Vorrichtung gemäß jedem der obigen Ansprüche zur Datenübertragung an eine Client-Station (350), wobei die genannte Server-Station (300) folgendes umfasst:

ein Mittel für den Empfang eines Berechtigungstokens (322) von einer Berechtigungsstation (112) zusammen mit einer Datenanforderung (360);

ein Mittel für den Empfang einer Kopie (374) des genannten Berechtigungstokens (322) von der genannten Client-Station (350) als Bestandteil einer Nachricht (375), die einen Befehl zum Aufbau einer Verbindung zwischen der genannten Server-Station (300) und der genannten Client-Station (350) enthält; und

12. Ein Verfahren zur Datenübertragung zwischen einer Client- Station (350) und einer Server-Station (300), wobei das genannte Verfahren die folgenden Schritte umfasst:

Abgabe einer Datenanforderung (360) von der genannten Client-Station (350) an eine Systemberechtigungsstation (112);

Senden eines Berechtigungstokens (322) von der genannten Systemberechtigungsstation (112) an die genannte Server- Station (300) zusammen mit der genannten Anforderung von der genannten Client-Station (350);

Senden einer Kopie (374) des genannten Berechtigungstokens (322) von der genannten Systemberechtigungsstation (112) an die genannte Client-Station (350);

Anforderung einer Verbindung zur genannten Server-Station (300), wobei die genannte Verbindung über einen Befehl (375) angefordert wird, der von der genannten Client- Station (350) an die genannte Server-Station (300) gesendet wird, wobei der genannte Befehl (375) die genannte Kopie (374) des genannten Berechtigungstokens (322) umfasst; und

Validierung der genannten Kopie (374) des genannten Berechtigungstokens (322) durch die genannte Server- Station (300), wobei die genannte Validierung durch Vergleich der genannten Kopie (374) des genannten Berechtigungstokens (322) mit dem genannten Berechtigungstoken (322) erfolgt, wobei die genannte Validierung erfolgreich ist, wenn die genannten Tokens (322, 374) übereinstimmen; und

Aufbau der genannten Verbindung zwischen der genannten Client-Station (350) und der genannten Server-Station (300), nachdem die genannte Kopie (374) des genannten Berechtigungstokens (322) von der genannten Server-Station (300) validiert wurde.

13. Ein Verfahren gemäß Anspruch 12, wobei das genannte Senden eines Berechtigungstokens (322) mindestens einen der nachfolgend aufgeführten Schritte umfasst:

Senden eines generischen Berechtigungstokens;

Senden eines wiederverwendbaren Berechtigungstokens;

Verschlüsselung des genannten Berechtigungstokens;

Senden des genannten Berechtigungstokens an einen ersten IOP-Verbindungsmanager (300) der Server-Station sowie an einen zweiten IOP-Verbindungsmanager (300) der Server- Station.

14. Ein Verfahren gemäß Anspruch 12 oder 13, wobei das genannte Senden einer Kopie (374) des genannten Berechtigungstokens (322) mindestens einen der folgenden Schritte umfasst:

Verschlüsselung der genannten Kopie des genannten Berechtigungstokens;

Senden der genannten Kopie des genannten Berechtigungstokens an einen ersten Verbindungsmanager (350) der Client-Station sowie an einen zweiten Verbindungsmanager (350) der Client-Station;

Senden der genannten Kopie des genannten Berechtigungstokens an eine erste Client-Station (350) sowie an eine zweite Client-Station (350).

15. Ein Verfahren gemäß jedem der obigen Ansprüche 12 bis 14, wobei der genannte Schritt des Aufbaus einer Verbindung mindestens einen der folgenden Schritte umfasst:

Bericht des Ergebnisses des genannten Validierungsschritts an den genannten IOP-Verbindungsmanager (350) der Client- Station;

Bericht des Ergebnisses des genannten Validierungsschritts an die genannte Systemberechtigungsstation (112);

Bericht des Ergebnisses des genannten Validierungsschritts an die genannte Client-Station (350);

Bericht des Ergebnisses des genannten Validierungsschritts an die genannte Berechtigungsstation (112).

16. Ein Verfahren gemäß jedem der obigen Ansprüche 12 bis 15, wobei der genannte Schritt des Empfangs mindestens einen der folgenden Schritte umfasst:

Verschlüsselung des genannten Berechtigungstokens;

Empfang des genannten Berechtigungstokens an einer ersten Server-Station (300) und an einer zweiten Server-Station (300);

Empfang eines generischen Berechtigungstokens;

Empfang eines wiederverwendbaren Berechtigungstokens;

Empfang eines Einmal-Berechtigungstokens.

17. Ein Verfahren gemäß jedem der obigen Ansprüche 12 bis 16, wobei der genannte Validierungsschritt mindestens einen der folgenden Schritte umfasst:

Verschlüsselung des genannten Berechtigungstokens;

Entschlüsselung des genannten Berechtigungstokens;

Entschlüsselung des genannten Berechtigungstokens und der genannten Kopie des genannten Berechtigungstokens.