DE10296804B4

DE10296804B4 - Verfahren und System zum Autorisieren des Zugriffs auf Betriebsmittel auf einem Server

Info

Publication number: DE10296804B4
Application number: DE10296804.7T
Authority: DE
Inventors: Victor Lortz
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2001-05-11
Filing date: 2002-05-09
Publication date: 2015-11-26
Anticipated expiration: 2022-05-10
Also published as: DE10296804T5; WO2002093872A1; US20020169986A1; HK1064839A1; US7107610B2; CN1507732A; CN100488190C; TWI223949B

Abstract

Verfahren, welches umfasst: – Empfangen einer Betriebsmittelanforderung von einem ersten Nachfrager, wobei die Betriebsmittelanforderung Autorisierungsnachweise und einen Identifikator für eine Operation umfasst, die bezüglich eines in der Betriebsmittelanforderung spezifizierten Betriebsmittels ausgeführt werden soll, wobei die Autorisierungsnachweise ein digitales Zertifikat umfassen, das konform zu einer Simple Public Key Infrastructure, SPKI, ist, – Übersetzen der Betriebsmittelanforderung in eine Anforderung für eine Betriebsmittelabfrage, wobei das Übersetzen Abbilden der Autorisierungsnachweise und des Identifikators für eine auszuführende Operation, die in der Betriebsmittelanforderung enthalten sind, auf einen Identifikator der Autorisierungsnachweise und einen in der Anforderung für eine Betriebsmittelabfrage enthaltenen Betriebsmittel-Identifikator enthält, und – Übermitteln der Anforderung für eine Betriebsmittelabfrage an einen Autorisierungsdienst, wobei der Autorisierungsdienst ferner eine Betriebsmittel-Datenstruktur nach einem Betriebsmittelknoten auf der Grundlage der Anforderung für eine Betriebsmittelabfrage durchsucht, wobei der Betriebsmittelknoten einen Betriebsmittelautorisierungsparameter zum Darstellen des Autorisierungsniveaus enthalten soll, das notwendig ist, um die Operation bezüglich des Betriebsmittels auszuführen, wobei das Autorisierungsniveau aus einer Gruppe ist, die aus Owner-Niveau, Editor-Niveau, Review-Niveau und None-Niveau besteht, und – Bestimmen, ob der erste Nachfrager autorisiert ist, die Operation bezüglich des Betriebsmittels auszuführen, auf der Grundlage dessen, ob die Autorisierungsnachweise und der ...

Description

Hintergrund
Diese Erfindung betrifft die Autorisierung für Betriebsmittel (Ressourcen).
Eine Funktion eines Servercomputers, der in einem Netzwerk läuft, besteht darin, Betriebsmittel mit Client-Computern zu teilen und zu verwalten. Bevor ein Client-Computer auf eine bestimmte Ressource zugreifen kann, sollte der Client von dem Server-Computer authentifiziert und autorisiert werden. Ein Ziel des Authentifizierungsprozesses besteht darin, die Identität des Clients zu authentifizieren, der versucht, Zugriff auf die Ressourcen des Servers zu nehmen. Wenn der Client authentifiziert worden ist, kann der Server den Autorisierungsprozess durchführen und ermitteln, welche Rechte der Client-Computer hinsichtlich der geteilten Betriebsmittel ausüben darf.
Die US 5941947 A offenbart ein Verfahren, welches umfasst: Empfangen einer Betriebsmittelanforderung von einem ersten Nachfrager, wobei die Betriebsmittelanforderung Autorisierungsnachweise und einen Identifikator für eine Operation umfasst, die bezüglich eines Betriebsmittels ausgeführt werden soll, Abbilden der Autorisierungsnachweise und des Indentifikators für eine auszuführende Operation, die in der Betriebsmittelanforderung enthalten sind, auf einen Betriebsmittel-Identifikator, Durchsuchen einer Betriebsmittel-Datenstruktur nach einem Betriebsmittelknoten auf der Grundlage des Betriebsmittel-Identifikators und Bestimmen, ob der erste Nachfrager autorisiert ist, die Operation bezüglich des Betriebsmittels auszuführen, auf der Grundlage dessen, ob die Autorisierungsnachweise und der Identifikator der auszuführenden Operation, die in der Betriebsmittelanforderung enthalten sind, einem Betriebsmittel-Autorisierungsparameter entsprechen, welcher dem Betriebsmittelknoten zugeordnet ist.
Kurze Beschreibung der Zeichnungen
1 illustriert ein Autorisierungssystem.
2 ist eine Autorisierungs-Betriebsmittel-Datenstruktur.
3 ist ein Flußdiagramm eines Verfahrens zum Autorisieren einer Betriebsmittelanforderung.
4 illustriert eine Betriebsmittelanforderung.
5 illustriert eine Anforderung für eine Betriebsmittelabfrage.
Detaillierte Beschreibung
Wie in 1 gezeigt ist, umfaßt ein Autorisierungssystem 10 Clienten 12a bis 12n, welche mit einem Server 16 über Kommunikationswege 9a bis 9n und einem Netzwerk 14 kommunizieren können. Das Netzwerk kann z. B. das Internet, ein lose verwaltetes Verbrauchernetzwerk, ein lokales Netz (LAN), ein weiträumiges Netz (WAN) oder ein anderes Computernetzwerk sein. Der Server 16 verwaltet die Betriebsmittel 18a bis 18n, welche Informationsbetriebsmittel (Informationsressourcen) umfassen, und kommuniziert mit diesen über Betriebsmittelverbindungen, wie ein LAN. Die Informationsbetriebsmittel können Dateisysteme und Hardwarebetriebsmittel, wie Modems, Drucker oder Scanner, umfassen.
Jedem Client 12a bis 12n können entsprechende Authentifizierungsnachweise zugewiesen sein. Zum Beispiel ist dem Client 12a der Authentifizierungsnachweis 11 zugewiesen. Jedem Client 12a bis 12n sind auch Autorisierungsnachweise zugeordnet, welche das Berechtigungs- oder Privilegniveau bzw. -niveaus angeben, die dem Client zugeordnet sind. Wie in 1 dargestellt ist, sind dem Client 12a die Autorisierungsnachweise 13 zugeordnet. Jedem Client 12a bis 12n ist auch eine Betriebsmitteloperation zugewiesen, welche eine Operation darstellt, welche der Client mit Hilfe der Ressource ausführen möchte. Beispielsweise ist dem Client 12a eine Betriebsmitteloperation 15 zugeordnet, welche eine Operation zum Zugreifen auf eine Datei, die sich auf einem Dateisystem befindet, zum Kommunizieren über ein Modem, zum Drucken von Unterlagen mit Hilfe von Printerressourcen oder eine andere Operation darstellen kann.
Jeder Client 12a bis 12n kann eine Authentifizierungs-Anforderung erzeugen, welche Authentifizierungsnachweise für die Authentifizierung umfaßt. Zum Beispiel erzeugt der Client 12a eine Authentifizierungs-Anforderung 31, welche die Authentifizierungsnachweise 11 umfaßt. Die Anforderung 31 wird an den Server 16 gerichtet, so daß die Identität des Client 12a durch den Server authentifiziert werden kann, wenn eine Verbindung mit dem Server über das Netzwerk 14 hergestellt wird. Die Authentifizierungsnachweise können einen Namen und ein Paßwort umfassen, die dem Client 12a zugewiesen sind. Alternativ können die Authentifizierungsnachweise 11 dadurch implementiert werden, daß ein Paar von privaten und öffentlichen Schlüsseln verwendet wird, wie es in der Public Key Infrastructure (PKI; Infrastruktur öffentlicher Schlüssel) verwendet wird.
Jeder Client 12a bis 12n kann Betriebsmittelanforderungen über das Netzwerk 14 erzeugen, um auf die Betriebsmittel 18a bis 18n, die von dem Server verwaltet werden, zuzugreifen. Zum Beispiel kann der Client 12a eine Betriebsmittelanforderung 32 erzeugen. Die Betriebsmittelanforderung 32 umfaßt die Autorisierungsnachweise 13, die von dem Server 16 verwendet werden, um festzustellen, ob der Client die Erlaubnis hat, auf das oder die angeforderten Betriebsmittel zuzugreifen. Die Autorisierungsnachweise 13 können implementiert werden, indem eine Autorisierungszertifikat-Technik verwendet wird, wie das Verfahren, das in der Simple Public Key Infrastructure (SPKI; einfache Infrastruktur öffentlicher Schlüssel) verwendet wird. Zusätzlich kann die Betriebsmittelanforderung 32 Informationen umfassen, welche für eine Operation stehen, die unter Verwendung des angegebenen Betriebsmittels ausgeführt werden soll.
Ein Client, wie der Client 12a, kann seine Autorisierungsnachweise 13 auf einen zweiten Client delegieren. Mit Hilfe dieser Delegationstechnik kann der zweite Client auf den Server mit denselben Autorisierungsnachweisen wie der Client 12a zugreifen. Der Server 16 behandelt die Nachweise beider Clients in äquivalenter Weise.
Ein Systemadministrator 17 ist für die Verwaltung des Servers 16 und seiner Betriebsmittel 18a bis 18n verantwortlich. Die Verantwortlichkeiten können das Hinzufügen/Löschen der Betriebsmittel 18a bis 18n zu dem Server 16 bzw. von dem Server 16 umfassen. Der Administrator kann Verwaltungsfunktionen mit Hilfe eines Anwenderprogramms 20 im Zusammenwirken mit einem Betriebssystem (O/S) 62, wie dem Betriebssystem Windows NT^TM, durchführen. Diese Programme können in einem Speicher 63, zum Beispiel einem DRAM (Dynamic Random Access Memory/dynamischer Direktzugriffsspeicher), gespeichert sein und durch eine CPU (Central Processing Unit) 64, wie einem Intel Pentium^®-Prozessor, ausgeführt werden. Das Anwenderprogramm 20 kann eine Benutzerschnittstelle 21 umfassen, um eine visuelle Darstellung eines Autorisierungs-Rahmenwerks 23 und der zugeordneten Betriebsmittel 18a bis 18n zur Verfügung zu stellen. Eine Anwenderprogramm-Schnittstelle (API/Application Program Interface) 22 kann eine Standardkommunikationsschnittstelle zwischen dem Anwenderprogramm 20 und dem Autorisierungs-Rahmenwerk 23 bilden. Das Autorisierungs-Rahmenwerk 23 umfaßt eine Betriebsmittelautorisierungs-Datenstruktur (Betriebsmittelstruktur) 26, welche verwendet wird, um eine Beziehung zwischen symbolischen Betriebsmittelnamen, die einem jeweiligen Betriebsmittel entsprechen, herzustellen und kann andere Informationen umfassen, welche die Betriebsmittelautorisierung betreffen.
Ein Betriebsmittelmanager 25 ist ein Programmodul, das mit dem Anwenderprogramm 20 über den Pfad 65 kommunizieren kann und für das Erzeugen und Verwalten der Betriebsmittelstruktur 26 über den Pfad 29 verantwortlich ist. Er kann auch für das Abbilden von Betriebsmittelanforderungen 32, die von Clients erzeugt werden, auf eine entsprechende das Betriebsmittel betreffende Information verantwortlich sein, die nötig ist, um der Anforderung zu entsprechen. Die Ergebnisse der Abbildungsoperation können zu einem Autorisierungsdienst 27 kommuniziert werden, indem eine Betriebsmittelabfrage-Anforderung 34 über einen Pfad 35 ausgegeben wird.
Der Autorisierungsdienst 27 führt ein Programm aus, das dafür verantwortlich ist, festzustellen, ob der Client 12a, der die Betriebsmittelanforderung 32 erzeugt hat, autorisiert ist, auf das angeforderte Betriebsmittel 18a bis 18n zuzugreifen. Der Dienst 27 durchsucht die Betriebsmittelstruktur 26 und verifiziert, ob der Client 12a die erforderliche Autorisierung besitzt, zum Teil auf der Grundlage der Autorisierungsnachweise 13, welche die Betriebsmittelanforderung 32 begleiten.
Der Administrator 17, der als Autor einer Richtlinie (Policy) fungiert, kann auf den Betriebsmittelmanager 25 zugreifen, um die Betriebsmittelstruktur 26 auf der Grundlage von Autorisierungsrichtlinien zu konstruieren, die sich auf die Betriebsmittel 18a bis 18n beziehen. Die Richtlinien können festlegen, welche Autorisierungsniveaus die Clients 12a bis 12n haben müssen, um die geforderte Operation, die in der Betriebsmittelanfrage 32 enthalten war, auszuführen.
Wie in 2 gezeigt ist, kann die Betriebsmittelstruktur 26 als Datenstruktur nach Art eines gerichteten Graphen implementiert werden, beispielsweise eine Datenstruktur nach Art eines gerichteten Baums. Die Betriebsmittelstruktur 26 entspricht einem Betriebsmittelraum, welcher die Namen von Betriebsmitteln und Gruppen von Betriebsmitteln 18a bis 18n darstellt. Die Betriebsmittelstruktur 26 umfaßt eine Hierarchie von Knoten 50a bis 50n. Ein Stammknoten (root node) 50a bildet einen Ankerpunkt für die zusätzlichen Knoten 50b bis 50n. Jedem Knoten ist ein entsprechender Knotenname 51a bis 51n und ein Knotenidentifikator 52a bis 52n zugeordnet. Zum Beispiel besitzt der Knoten 50c den Knotennamen 51c ”Modem” und den Knotenidentifikator 52c ”key3”. Jeder Knoten 50a bis 50n kann durch seinen Knotennamen, den Knotenidentifikator oder eine Kombination von beidem adressiert werden.
Die Betriebsmittelstruktur 26 kann durch Betriebsmitteleigentümer, wie einen Verkäufer von Betriebsmitteln, konstruiert werden, der die Knotenidentifikatoren 52a bis 52n eines Autorisierungszweigs (sub tree) definieren kann. Der Zweig kann anschließend an einem geeigneten Punkt in der Betriebsmittelstruktur durch den Richtlinienautor eingefügt werden. Ein Autorisierungszweig kann eine Teilmenge der Knoten in einer Betriebsmittelstruktur umfassen. Beispielsweise kann ein Zweig den Modem-Zweig umfassen, der durch den Knoten 50c als Basis des Zweigs und die Knoten 50d und 50e als Zweige des Zweigs repräsentiert wird. Alternativ kann der Richtlinienautor von Hand Knoten in die Struktur 26 entsprechend der Präferenz des Eigentümers des Betriebsmittels einfügen. Von Hand eingefügte Knoten können Schlüssel umfassen, die dynamisch durch das Anwenderprogramm 20 zugewiesen werden. Da jedoch die ”Schlüssel” intern generiert sein können und nicht ein wirkliches Paar von öffentlichem und privatem Schlüssel sein müssen, besteht möglicherweise keine Notwendigkeit, ein Vertrauensmodel (trust model) für die internen Schlüssel aufzubauen.
Die Betriebsmittelstruktur 26 unterstützt einen ”Mountpoint”-Knoten (”mount point” node), an dem der Administrator, der als Richtlinienautor agiert, absteigende Richtlinien (top down policies) zum Zugriff auf ein Betriebsmittel erstellen kann, ohne die internen Details kennen zu müssen, wie der Autorisierungszweig dieses Betriebsmittels strukturiert ist. Der Begriff ”Mountpoint” ist analog zu dem Mountpoint und der Zugangsberechtigung bei einem Dateisystem. Zum Beispiel ist der Knoten 50d ein Hersteller-Diagnostik-Mountpoint, an dem der Hersteller des Modems einen Satz von Richtlinien vorsehen kann, welche die Rechte vorschreiben, die erforderlich sind, um auf die diagnostischen Merkmale des Betriebsmittels Modem zuzugreifen.
Jeder Knoten 50a bis 50n in der Struktur 26 kann auch einer entsprechenden Zugriffskontrolliste (ACL; Access Control List) 53a bis 53n zugeordnet sein, welche entsprechende Autorisierungsnachweise 58 und ein Autorisierungsniveau 59 umfassen kann. Das Autorisierungsniveau 59 bezieht sich auf das Autorisierungsniveau, das erforderlich ist, um auf ein Betriebsmittel zuzugreifen. In einer Implementierung können die Autorisierungsniveaus einen der vier folgenden Werte haben: (1) Owner (Eigentümer), (2) Editor, (3) Reviewer (Besichtiger) oder (4) None (Keine). Das Niveau ”Owner” gestattet den vollständigen administrativen Zugriff auf das Betriebsmittel, ”Editor” gestattet den Lese/Schreib-Zugriff auf das Betriebsmittel, ”Reviewer” gestattet den Lesezugriff auf das Betriebsmittel und ”None”, welches das Standardniveau bzw. das implizite Niveau ist, verweigert allen Zugriff auf ein Betriebsmittel. Die Berechtigung zum Editieren von Teilen der Betriebsmittelstruktur 26 kann durch das Autorisierungsniveau kontrolliert werden. Um das Editieren eines Zweigs, zum Beispiel das Hinzufügen oder Löschen von abgeleiteten Knoten, das Ändern von Namen, Identifikatoren und ACLs, zu gestatten, sollte das Autorisierungsniveau des Knotens auf ”Owner” gesetzt sein.
Die Autorisierungsnachweise 58 können ein digitales Zertifikat darstellen, das auf den Nachweisen des Client beruht, der auf das Betriebsmittel zugreifen möchte. Zum Beispiel hat der Knoten 50c eine ACL 53c mit einem Wert von ”key3 (key2=Owner)”, was angibt, daß die Autorisierungsnachweise ”key3” zu dem Autorisierungsniveau ”Owner” und den Autorisierungsnachweisen von ”key2” delegiert werden. Die Delegation von Berechtigungsnachweisen wird durch den Pfeil 54c angedeutet. Daher würden die Autorisierungsnachweise an dem Knoten 50b, die dem Knotenidentifikator 52b (”key2”) entsprechen, überprüft werden, um die Autorisierung festzustellen. Die Pfeile 54a bis 54n stellen Autorisierungsnachweise dar, die auf einer Delegation einer Berechtigung von einem abgeleiteten Knoten auf einen übergeordneten Knoten beruhen.
Wie in 3 angedeutet ist, erzeugt (100) der Client 12a eine Betriebsmittelanforderung, die an den Server 16 gerichtet ist, über das Netzwerk 14. Für den Zweck der nachfolgenden Erörterung wird davon ausgegangen, daß der Client 12a in der Lage ist, mit dem Server 16 zu kommunizieren, da der Client bereits durch den Server im Wege einer früheren Authentifizierungsanforderung 31 authentifiziert worden ist. Die Betriebsmittelanforderung 32 (4) umfaßt Autorisierungsnachweise 13, wie ein signiertes digitales Zertifikat, und eine von dem Client angegebene Betriebsmitteloperation 15. Bei diesem Beispiel haben die Autorisierungsnachweise 13 den Wert ”Dad” und die Betriebsmitteloperation 15 hat den Wert ”Set Modem Configuration” (Einstellen der Modemkonfiguration).
Nachdem die Betriebsmittelanforderung 32 von dem Server 16 empfangen worden ist, bildet (102) der Betriebsmittelmanager 25 die Betriebsmittelanforderung auf einen Betriebsmittelnamen (oder einen anderen Identifikator) und ein Autorisierungsniveau auf der Grundlage der Information in der Betriebsmittelanforderung ab.
Der Betriebsmittelmanager 25 übersetzt (103) eine Anforderung für eine Betriebsmittelabfrage 34, teilweise auf der Grundlage des Inhaltes der Betriebsmittelanforderung 32. Wie in 5 gezeigt ist, umfaßt die Betriebsmittelabfrage-Anforderung 34 einen Betriebsmittelnamen 41, welcher dem Betriebsmittel entspricht, das aus der Betriebsmitteloperation 15 der Betriebsmittelanforderung 32 abgeleitet worden ist. Die Anforderung 34 umfaßt auch ein Autorisierungsniveau 42, welches die Erlaubnis darstellt, die für den Client nötig ist, um die erforderliche Operation auszuführen. Zusätzlich identifiziert die Anforderung 34 die Autorisierungsnachweise 43, welche den Autorisierungsnachweisen 13 in der Betriebsmittelanforderung 32 entsprechen.
Zum Beispiel würde unter Verwendung der vorangehenden Betriebsmittelanforderung 32 der 4 der Betriebsmittelmanager 25 festlegen, daß (1) der Betriebsmittelname 41 ”key3/User config” ist, der aus der Betriebsmitteloperation 15 ”Set Modem Configuration” abgeleitet ist, (2) ”Owner” das erforderliche Autorisierungsniveau 42 eines speziellen Betriebsmittelknotens in der Struktur 26 ist und (3) ”Dad” der Autorisierungsnachweis 43 ist, welcher dem Autorisierungsnachweis 13 entspricht, der in der Betriebsmittelanforderung 32 identifiziert worden ist. Der Betriebsmittelmanager 25 verfolgt die Information, die sich auf die Betriebsmittelstruktur 26 bezieht, einschließlich der Betriebsmittelnamen und der zugehörigen Autorisierungsniveaus.
Wie in 3 angedeutet ist, übermittelt (104) der Betriebsmittelmanager 25 die Betriebsmittelabfrage-Anforderung 34 an den Autorisierungsdienst 27. Bei Empfang der Anforderung 34 sucht der Autorisierungsdienst 27 nach dem Betriebsmittelnamen in der Betriebsmittelstruktur 26 und wertet (106) die Autorisierungsnachweise und das Autorisierungsniveau des Client anhand der Autorisierungsinformation in der ACL an dem entsprechenden Knoten aus. Wenn zum Beispiel die Betriebsmittelabfrage-Anforderung 34 verwendet würde, die in 5 dargestellt ist, würde der Autorisierungsdienst 27 die Ressourcenstruktur 26 durchsuchen und feststellen, daß der Knoten 50e den Knotennamen 51e ”user config” und einen Knotenidentifikator 52e ”key5” besitzt. Der Knoten 50e ist ein abgeleiteter Knoten des übergeordneten Knotens 50c, was durch den Pfeil 54e angedeutet ist.
Wenn das Ergebnis der Auswertung ergibt (108), daß der Client auf der Grundlage der Information in der ACL autorisiert ist, auf das Betriebsmittel zuzugreifen, gibt der Autorisierungsdienst 27 eine Erfolgsmeldung an den Betriebsmittelmanager 25 zurück (110). Der Betriebsmittelmanager 25 kann die Operation, die von dem Client gefordert worden war, ausführen (112), da der Client autorisiert worden ist.
Wenn man die Betriebsmittelanforderung 32 der 4 verwendet, würde der Autorisierungsdienst 27 die Knoten in der Betriebsmittelstruktur 26 durchlaufen und den Satz der Nachweise ”key5 (key3=owner)”, beginnend an dem Knoten 50e, verarbeiten, dem Pfeil 54e zu den Nachweisen des Knotens 50c ”key3 (key2=owner)” folgen und dem Pfeil 54c zu dem Knoten 50b folgen und Bezug auf ACL2 ”key2 (Dad=Owner)” nehmen. Wenn der Client einen Autorisierungsnachweis besitzt, der auf den Wert ”Dad” gesetzt ist, ist er als ”Owner” berechtigt, die Operation ”Set Modem Configuration” auszuführen.
Wenn andererseits (in Block 108) die dem Knoten zugeordnete ACL dem Client keinen Zugriff gewährt, sucht (114) der Autorisierungsdienst 27 nach einem übergeordneten Knoten mit einer ACL mit einem hinreichend hohen Autorisierungsniveau, um dem Client den Zugriff auf das Betriebsmittel zu gestatten. Wenn ein übergeordneter Knoten gefunden wird, werden die ACL, das zugeordnete Autorisierungsniveau und Autorisierungsnachweise zu dem Autorisierungsdienst 27 weitergeleitet. Der Prozeß würde dann zu dem Block 106 zurückkehren, wo der Autorisierungsdienst 27 Nachweise des Client mit Information in der ACL vergleicht.
Wenn jedoch (in Block 114) die Suchergebnisse anzeigen, daß kein übergeordneter Knoten mit einer auf einem hinreichend hohen Autorisierungsniveau vererbten ACL existiert, gibt der Autorisierungsdienst 27 eine Fehlermeldung an den Betriebsmittelmanager 25 zurück. Dem Betriebsmittelmanager wird der Zugriff auf das Betriebsmittel verwehrt (118) und er kann die Abweisung an den Client kommunizieren.
Wenn ein Client mit Autorisierungsnachweisen, die vorangehend identifiziert worden sind, wieder versuchen würde, auf den ”Mountpoint”, welcher dem Knoten 50d entspricht, Zugriff zu nehmen, würde dem Client der Zugriff verwehrt werden, da der Knoten 50d nur das Autorisierungsniveau ”Reviewer” an seinen übergeordneten Knoten 50c delegiert, was durch den Pfeil 54d gezeigt ist. Der Knoten 50c besitzt eine ACL3 mit einem Wert ”key3 (key2=owner)”, was angibt, daß die Nachweise an den Knoten 50b delegiert worden sind, was durch den Pfeil 54c gezeigt ist. Bezug nehmend auf den Knoten 50b mit dem Knotennamen 51b ”DenPC”, autorisiert die Zuordnung des Autorisierungsniveaus ”key2 (Dad=Owner)” in ACL 53b daher nicht ”Dad”, auf den ”Mountpoint”-Knoten 50d zuzugreifen.
Unter Verwendung der vorangehend genannten Techniken kann ein Verkäufer von Betriebsmitteln, wie ein Hersteller, seinen eigenen öffentlichen bzw. privaten Schlüssel erzeugen und von dem Client verlangen, daß der Schlüssel verwendet wird, um Zugriff auf bestimmte Eigenschaften des Modems, wie die Diagnostikmerkmale des Modems, Zugriff zu nehmen. Durch das Begrenzen des Zugriffs auf Diagnostikmerkmale auf autorisierte Clients kann der Hersteller das Autorisierungs-Rahmenwerk 23 verwenden, um Zollsicherheitsvorschriften umzusetzen.
Die vorangehenden Techniken können es gestatten, daß die Autorisierung von mehreren Anwendungen geteilt wird, was verteilte Systeme umfaßt, die verschiedene administrative Domänen überspannen. Weiterhin können die Techniken angewendet werden, um Probleme zu lösen, die sich auf die Sicherung von Dienstvermittlungsplattformen für den Verbrauchermarkt beziehen. Die Techniken können auch im Kontext von Lösungen des elektronischen Geschäftsverkehrs (”E-Business”) entweder für Business to Business- oder Business to Consumer-Dienstanwendungen verwendet werden, wobei die Endpunkte der Kommunikation inhärent Teil von verschiedenen administrativen Domänen sind.
Auch wenn vier Autorisierungsniveaus vorangehend erörtert wurden, ist es möglich, die Granularität der Niveaus zu erhöhen.
Verschiedene Eigenschaften des Systems können in Hardware, Software oder in einer Kombination von Hardware und Software implementiert werden. Beispielsweise können einige Aspekte des Systems in Computerprogrammen implementiert werden, die auf programmierbaren Computern laufen. Jedes Programm kann in einer prozedurorientierten oder objektorientierten Hochprogrammiersprache implementiert sein, um mit einem Computersystem zu kommunizieren. Weiterhin kann jedes solches Computerprogramm auch auf einem Speichermedium gespeichert sein, beispielsweise einem Festwertspeicher (ROM), das von einem programmierbaren Universalprozessor oder Spezialprozessor gelesen werden kann, um den Computer zu konfigurieren und zu betreiben, wenn das Speichermedium von dem Computer gelesen wird, um die vorangehend beschriebenen Funktionen auszuführen.
Andere Implementierungen liegen im Umfang der folgenden Ansprüche.

Claims

Verfahren, welches umfasst: – Empfangen einer Betriebsmittelanforderung von einem ersten Nachfrager, wobei die Betriebsmittelanforderung Autorisierungsnachweise und einen Identifikator für eine Operation umfasst, die bezüglich eines in der Betriebsmittelanforderung spezifizierten Betriebsmittels ausgeführt werden soll, wobei die Autorisierungsnachweise ein digitales Zertifikat umfassen, das konform zu einer Simple Public Key Infrastructure, SPKI, ist, – Übersetzen der Betriebsmittelanforderung in eine Anforderung für eine Betriebsmittelabfrage, wobei das Übersetzen Abbilden der Autorisierungsnachweise und des Identifikators für eine auszuführende Operation, die in der Betriebsmittelanforderung enthalten sind, auf einen Identifikator der Autorisierungsnachweise und einen in der Anforderung für eine Betriebsmittelabfrage enthaltenen Betriebsmittel-Identifikator enthält, und – Übermitteln der Anforderung für eine Betriebsmittelabfrage an einen Autorisierungsdienst, wobei der Autorisierungsdienst ferner eine Betriebsmittel-Datenstruktur nach einem Betriebsmittelknoten auf der Grundlage der Anforderung für eine Betriebsmittelabfrage durchsucht, wobei der Betriebsmittelknoten einen Betriebsmittelautorisierungsparameter zum Darstellen des Autorisierungsniveaus enthalten soll, das notwendig ist, um die Operation bezüglich des Betriebsmittels auszuführen, wobei das Autorisierungsniveau aus einer Gruppe ist, die aus Owner-Niveau, Editor-Niveau, Review-Niveau und None-Niveau besteht, und – Bestimmen, ob der erste Nachfrager autorisiert ist, die Operation bezüglich des Betriebsmittels auszuführen, auf der Grundlage dessen, ob die Autorisierungsnachweise und der Identifikator der auszuführenden Operation, die der Betriebsmittelanforderung zugeordnet sind, dem Betriebsmittel-Autorisierungsparameter entsprechen, welcher dem Betriebsmittelknoten zugeordnet ist.
Verfahren nach Anspruch 1, bei dem das Durchsuchen das Durchsuchen von Betriebsmittelknoten umfasst, welche jeweils ein Betriebsmittel darstellen und einen Betriebsmittel-Identifikator umfassen.
Verfahren nach Anspruch 1, bei dem das Durchsuchen das Durchsuchen einer Struktur entsprechend einem gerichteten Graphen umfasst.
Verfahren nach Anspruch 1, bei dem die Autorisierungsnachweise eines abgeleiteten Knotens an einen übergeordneten Knoten in der Betriebsmittel-Datenstruktur delegiert werden.
Verfahren nach Anspruch 4, bei dem die Betriebsmittelanforderung auf der Grundlage der delegierten Nachweise gehandhabt wird.
Verfahren nach Anspruch 1, bei dem die Betriebsmittelanforderung von einem Client-Computer stammt und an einen Server-Computer über ein Netzwerk gerichtet wird.
Vorrichtung, welche umfasst: – einen Speicher zum Speichern einer Betriebsmitteldatenstruktur mit Betriebsmittelknoten, welche jeweils ein entsprechendes Betriebsmittel darstellen und einen entsprechenden Betriebsmittel-Identifikator und einen Betriebsmittelautorisierungs-Parameter aufweisen, und – einen Prozessor, der für Folgendes konfiguriert ist: – Empfangen einer Betriebsmittelanforderung von einem ersten Nachfrager, wobei die Betriebsmittelanforderung Autorisierungsnachweise und einen Identifikator für eine Operation umfasst, die hinsichtlich eines in der Betriebsmittelanforderung spezifizierten Betriebsmittels vorgenommen werden soll, wobei die Autorisierungsnachweise ein digitales Zertifikat umfassen, das konform zu einer SPKI ist, – Übersetzen der Betriebsmittelanforderung in eine Anforderung für eine Betriebsmittelabfrage, wobei das Übersetzen Abbilden der Autorisierungsnachweise und des Identifikators für eine auszuführende Operation, die in der Betriebsmittelanforderung enthalten sind, auf einen Identifikator der Autorisierungsnachweise und einen in der Anforderung für eine Betriebsmittelabfrage enthaltenen Betriebsmittel-Identifikator enthält, und – Übermitteln der Anforderung für eine Betriebsmittelabfrage an einen Autorisierungsdienst, wobei der Autorisierungsdienst ferner die Betriebsmittel-Datenstruktur nach einem Betriebsmittelknoten auf der Grundlage der Anforderung für eine Betriebsmittelabfrage durchsucht, wobei der Betriebsmittelknoten einen Betriebsmittelautorisierungsparameter zum Darstellen des Autorisierungsniveaus enthalten soll, das notwendig ist, um die Operation bezüglich des Betriebsmittels auszuführen, wobei das Autorisierungsniveau aus einer Gruppe ist, die aus Owner-Niveau, Editor-Niveau, Review-Niveau und None-Niveau besteht, und – Bestimmen, ob der erste Nachfrager autorisiert ist, die Operation bezüglich des Betriebsmittels auszuführen, auf der Grundlage dessen, ob die Autorisierungsnachweise und der Identifikator der auszuführenden Operation, die der Betriebsmittelanforderung zugeordnet sind, dem Betriebsmittel-Autorisierungsparameter entsprechen, welcher dem Betriebsmittelknoten zugeordnet ist.
Vorrichtung nach Anspruch 7, bei dem die Betriebsmittel-Datenstruktur eine Struktur entsprechend einem gerichteten Graphen umfasst.
Vorrichtung nach Anspruch 7, bei dem das Betriebsmittel-Autorisierungsniveaus von einem abgeleiteten Knoten an einen übergeordneten Knoten delegiert wird.
System, welches umfasst: – einen ersten Computer, der einem ersten Nachfrager entspricht und so konfiguriert ist, dass er Betriebsmittelanforderungen mit Nachweisen erzeugt, – einen zweiten Computer, der einen Speicher umfasst, der eine Betriebsmittel-Datenstruktur mit Betriebsmittelknoten speichert, welche jeweils ein entsprechendes Betriebsmittel darstellen und einen entsprechenden Betriebsmittel-Identifikator und ein Betriebsmittel-Autorisierungsniveau aufweisen, wobei der zweite Computer für Folgendes konfiguriert ist: – Empfangen einer Betriebsmittelanforderung von einem ersten Nachfrager, wobei die Betriebsmittelanforderung Autorisierungsnachweise und einen Identifikator für eine Operation umfasst, die bezüglich eines in der Betriebsmittelanforderung spezifizierten Betriebsmittels ausgeführt werden soll, wobei die Autorisierungsnachweise ein digitales Zertifikat umfassen, das konform zu einer SPKI ist, – Übersetzen der Betriebsmittelanforderung in eine Anforderung für eine Betriebsmittelabfrage, wobei das Übersetzen Abbilden der Autorisierungsnachweise und des Identifikators für eine auszuführende Operation, die in der Betriebsmittelanforderung enthalten sind, auf einen Identifikator der Autorisierungsnachweise und einen in der Anforderung für eine Betriebsmittelabrage enthaltenen Betriebsmittel-Identifikator enthält, und – Übermitteln der Anforderung für eine Betriebsmittelabfrage an einen Autorisierungsdienst, wobei der Autorisierungsdienst ferner eine Betriebsmittel-Datenstruktur nach einem Betriebsmittelknoten auf der Grundlage der Anforderung für eine Betriebsmittelabfrage durchsucht, wobei der Betriebsmittelknoten einen Betriebsmittelautorisierungsparameter zum Darstellen des Autorisierungsniveaus enthalten soll, das notwendig ist, um die Operation bezüglich des Betriebsmittels auszuführen, wobei das Autorisierungsniveau aus einer Gruppe ist, die aus Owner-Nivear, Editor-Niveau, Review-Niveau und None-Niveau besteht und – Bestimmen, ob der erste Nachfrager autorisiert ist, die Operation bezüglich des Betriebsmittels durchzuführen, auf der Grundlage dessen, ob die Autorisierungsnachweise und der Identifkator der auszuführenden Operation, die der Betriebsmittelanforderung zugeordnet sind, dem Betriebsmittel-Autorisierungsniveau entsprechen, das dem Betriebsmittelknoten zugeordnet ist, und – ein Netzwerk, über welches der erste und zweite Computer miteinander kommunizieren.
System nach Anspruch 10, bei dem die Betriebsmittel-Datenstruktur eine Struktur entsprechend einem gerichteten Graphen umfasst.
System nach Anspruch 10, bei dem die Autorisierungsnachweise eines abgeleiteten Knotens an einen übergeordneten Knoten delegiert werden.
System nach Anspruch 10, welches die Delegation von Autorisierungsnachweisen, die einem ersten Nachfrager zugeordnet sind, auf einen zweiten Nachfrager umfasst, wobei der zweite Nachfrager Betriebsmittel unter Verwendung der Autorisierungsnachweise von dem ersten Nachfrager anfordern kann, als ob er der erste Nachfrager wäre.
Artikel, welcher ein computerlesbares Medium umfasst, das von einem Computer ausführbare Anweisungen zum Veranlassen eines Computers zu Folgendem umfasst: – Empfangen einer Betriebsmittelanforderung von einem ersten Nachfrager, wobei die Betriebsmittelanforderung Autorisierungsnachweise und einen Identifikator für eine Operation umfasst, die bezüglich eines in der Betriebsmittelanforderung spezifizierten Betriebsmittels ausgeführt werden soll, wobei die Autorisierungsnachweise ein digitales Zertifikat umfassen, das konform zu einer SPKI ist, – Übersetzen der Betriebsmittelanforderung in eine Anforderung für eine Betriebsmittelabfrage, wobei das Übersetzen Abbilden der Autorisierungsnachweise und des Identifikators für eine auszuführende Operation, die in der Betriebsmittelanforderung enthalten sind, auf einen Identifikator der Autorisierungsnachweise und einen in der Anforderung für eine Betriebsmittelabfrage enthaltenen Betriebsmittel-Identifikator enthält, und – Übermitteln der Anforderung für eine Betriebsmittelabfrage an einen Autorisierungsdienst, wobei der Autorisierungsdienst ferner eine Betriebsmittel-Datenstruktur nach einem Betriebsmittelknoten auf der Grundlage der Anforderung für eine Betriebsmittelabfrage durchsucht, wobei der Betriebsmittelknoten einen Betriebsmittelautorisierungsparameter zum Darstellen des Autorisierungsniveaus enthalten soll, das notwendig ist, um die Operation bezüglich des Betriebsmittels auszuführen, wobei das Autorisierungsniveau aus einer Gruppe ist, die aus Owner-Niveau, Editor-Niveau, Review-Niveau und None-Niveau besteht, und – Bestimmen, ob der erste Nachfrager autorisiert ist, die Operation bezüglich des Betriebsmittels auszuführen, auf der Grundlage dessen, ob die Autorisierungsnachweise und der Identifikator der auszuführenden Operation, die der Betriebsmittelanforderung zugeordnet sind, dem Betriebsmittel-Autorisierungsparameter entsprechen, welcher dem Betriebsmittelknoten zugeordnet ist.
Artikel nach Anspruch 14, welcher Anweisungen zum Veranlassen des Computersystems zum Besitzen einer Datenstruktur entsprechend einem gerichteten Graphen mit Betriebsmittelknoten, welche Betriebsmittel darstellen und einen Betriebsmittel-Identifikator und ein Betriebsmittel-Autorisierungsniveau umfassen, aufweist.
Artikel nach Anspruch 14, welcher Anweisungen zum Veranlassen des Computersystems zum Delegieren der Autorisierungsnachweise eines abgeleiteten Knotens auf einen übergeordneten Knoten umfasst.
Artikel nach Anspruch 14, welcher Anweisungen zum Veranlassen des Computersystems zum Delegieren der Autorisierungsnachweise, die einen erstem Nachfrager zugeordnet sind, auf einen zweiten Nachfrager, um dem zweiten Nachfrager es zu gestatten, Ressourcen unter Verwendung der Autorisierungsnachweise des ersten Nachfragers anzufordern, als ob er der erste Nachfrager wäre, umfasst.