DE19954358A1

DE19954358A1 - Benutzerrollenzugriffssteuerung

Info

Publication number: DE19954358A1
Application number: DE1999154358
Authority: DE
Inventors: Lawrence M Besaw; Bruce C Welti; Judith C Walker
Original assignee: Hewlett Packard Co
Current assignee: HP Inc
Priority date: 1999-01-07
Filing date: 1999-11-11
Publication date: 2000-07-20
Also published as: JP2000207363A

Abstract

Die vorliegende Erfindung ist ein Verfahren und eine Vorrichtung zum Steuern des Benutzerzugriffs in einer Netzumgebung unter Verwendung von Benutzerrollen. Eine Benutzerrolle bestimmt, welche Funktion ein Benutzer besitzt, und kann einen Bereich einer Betriebsverantwortung definieren. Die Benutzerrollenzugriffssteuerung umfaßt eine oder mehrere Benutzerrollen und Zugriffsrechte, die bestimmen, welche Handlungen an Objekten durchgeführt werden können, wie z. B. das Ausführen eines URL oder das Konfigurieren einer Netzleitvorrichtung, und welche Benutzerrollen derartige Handlungen durchführen können. Daher wird die Benutzerrollenzugriffssteuerung verwendet, um eine Anfrage eines Benutzers zu bewilligen, wenn die eine oder die mehreren Benutzerrollen des benutzers ihm Zugriffsrechte erteilen, die ihn berechtigen, eine spezielle Handlung an einem speziellen Objekt durchzuführen. Bei einem bevorzugten Ausführungsbeispiel der Erfindung ist die Benutzerrollenzugriffssteuerung in einem Web-Browser implementiert, wobei einer oder mehrere URLs die Zugriffsrechte eines Benutzers bestimmen.

Description

Diese Erfindung bezieht sich auf das Gebiet der Systemsi cherheitsführung und insbesondere auf ein Verfahren zum Implementieren einer Benutzerzugriffssteuerung, um eine leichte Führung (Management) und Sicherheit in einer Netz umgebung durch die Verwendung von Benutzerrollen zu fördern.

Um eine leichte Führung (Benutzer sehen lediglich das, was sie benötigen, um ihre Arbeit auszuführen) und Sicherheit (Benutzer können lediglich Handlungen durchführen, zu denen sie berechtigt sind) in einer Netzumgebung zu fördern, ist es wichtig, steuern zu können, was Benutzer in einem System durchführen können. Um diese Ziele zu fördern, wird die Be nutzerzugriffssteuerung, die definiert, welche Objekte ein Benutzer verwalten kann, und welche Operationen ein Benutzer durchführen kann, weit verbreitet verwendet, indem es ermög licht wird, daß unterschiedlichen Benutzern unterschiedliche Privilegebenen zugewiesen werden können, und daß unter schiedliche Teile des Netzes geführt werden können.

Die Benutzerzugriffsteuerung wird bei existierenden Produk ten durch Domänen definiert. Der Ausdruck Domäne besitzt verschiedene Anwendungen, wird jedoch inoffiziell zum Be schreiben einer Gruppe von Objekten verwendet, die eine ge meinsame Führung (Management), eine gemeinsame Position oder gemeinsame Standards aufweist. Bei einer verteilten Umgebung ist es unumgänglich Komponenten oder Leute in eine Einheit (oder Domäne) zu gruppieren, da die Größe und die Komplexi tät einer derartigen Umgebung es unmöglich macht, jede Kom ponente oder jeden Benutzer als unabhängige Entität für Führungszwecke zu behandeln. Domänen werden daher verwendet, um die Größe und die Komplexität einer Führungsumgebung zu reduzieren, indem die Umgebung in interessierende Bereiche und Verantwortungsbereiche aufgeteilt wird. Im Zusammenhang mit einer Benutzerzugriffssteuerung kann sich eine Domäne auf einen Satz von Objekten, wie z. B. Ressourcen (Betriebs mittel), Leute, Privilegien oder Prozesse beziehen, die ei ner einzigen Führungspolitik unterworfen sind. Eine Domäne sollte derart gruppiert sein, daß die Elemente in der Gruppe mit einer einzigen Politik (Verfahrensweise) verwaltet wer den können. Beispielsweise kann eine Benutzerdomäne ein Satz von Benutzern sein, die für eine Lohnliste verantwortlich sind und die einer einzigen Politik unterworfen sind, die bestimmt, auf was sie zugreifen können, und eine Objektdomä ne kann ein Satz von Lohnlistendateien sein, die den gleichen Zugriffsrechten unterworfen sind. Die Mitglieder einer Domäne können einzelne Entitäten und/oder Domänen sein, und die gleiche Entität/die gleiche Domäne kann zu ei ner oder mehreren Domänen gehören.

Bei einer typischen Benutzerzugriffssteuerungsimplementation gibt es eine oder mehrere Benutzerdomänen, die einer oder mehreren Objektdomänen zugeordnet sind. Diese Zuordnung wird durch eine Zugriffsregel bestimmt, die spezifiziert, welche Operationen eine Benutzerdomäne an einer Objektdomäne durch führen kann. Eine Grundzugriffsregel spezifiziert eine Be nutzerdomäne, eine Objektdomäne und einen Operationssatz der Objektdomäne. Der Zugriff wird ermöglicht, wenn sich der Be nutzer, der die Anfrage durchführt, in der Benutzerdomäne der Regel befindet, sich das Objekt der Anfrage in der Ob jektdomäne der Regel befindet und sich der Operationsname in dem Operationssatz der Objektdomäne befindet. Der Zugriff wird verweigert, wenn der Benutzer, das Objekt, oder die Operation in der Anfrage auf keine existierende Zugriffs regel anwendbar ist. Beispielsweise spezifiziert die Zu griffsregel {Lohnliste, Lohnlisten_Dateien, {Lesen, Schrei ben}}, daß alle Benutzer in der Lohnlistenbenutzerdomäne Objekte der Benutzerrollen_Datei-Objektdomäne lesen können, und in dieselben schreiben können. Wenn unterschiedliche Benutzer unterschiedliche Teilsätze von Operationen inner halb der Lohnlistendomäne erfordern, dann müssen mehrere Zugriffsregeln erzeugt werden. Wenn dann die Lohnlistenbe nutzerdomäne eine Lohnlisten_Personal-Benutzerdomäne und eine Lohnlisten_Führung-Benutzerdomäne (Domänenmitglieder können andere Domänen sein) aufweist, und es dem Lohn listen_Personal lediglich ermöglicht ist, Lohnlisten_Dateien zu lesen, während es der Lohnlisten_Führung ermöglicht ist, zu lesen und zu schreiben, dann wird eine Zugriffsregel für das Lohnlisten_Personal {Lohnlisten_Personal, Lohnlisten_Da teien, Lesen} und eine weitere Zugriffsregel für die Lohn listen_Führung {Lohnlisten_Führung, Lohnlisten_Datei, {Lesen, Schreiben}} erzeugt.

Ein Problem des existierenden Modells der Benutzerzugriffs steuerung besteht darin, daß eine Berechtigung oftmals über bewilligt (übermäßig bewilligt) oder unterbewilligt (zu wenig bewilligt) wird. Das Überbewilligen und das Unterbe willigen einer Berechtigung kann von den Zielen der Objekt führung und der Sicherheitssteuerung abweichen. Das Überbe willigen einer Berechtigung kann ein System gegenüber Sicherheitslücken anfällig machen. Es sei beispielsweise an genommen, daß die Objektdomäne 1 mit einem Zugriff {Lesen, Schreiben, Erzeugen} definiert ist; und die Zugriffsregeln versehen die Benutzerdomäne 1 mit einem Lesezugriff auf die Objektdomäne 1 {Benutzerdomäne 1, Objektdomäne 1, Lesen}, die Benutzerdomäne 2 mit einem Lese/Schreib-Zugriff auf die Objektdomäne 1 {Benutzerdomäne 2, Objektdomäne 1, {Lesen, Schreiben}}, und die Benutzerdomäne 3 mit einem Lese/Schreib/Erzeugen-Zugriff auf die Objektdomäne 1 {Be nutzerdomäne 3, Objektdomäne 1, {Lesen, Schreiben, Erzeu gen}}. Es wird weiter angenommen, daß der Benutzer 1 ein Mitglied der Benutzerdomäne 1 für Führungszwecke, der Be nutzerdomäne 2 für Verwaltungszwecke und der Benutzerdomäne 3 für Operationszwecke ist, wie es der Fall sein kann, wenn ein Benutzer mehrere Rollen einnimmt oder für einen anderen Arbeitnehmer einspringt. Wenn sich der Benutzer 1 in dem System einträgt bzw. anmeldet, wird derselbe als ein Mit glied der Benutzerdomäne 1, der Benutzerdomäne 2 und der Benutzerdomäne 3 erkannt. Als ein Resultat kann ein Über bewilligen einer Berechtigung dort auftreten, wo die norma len Pflichten des Benutzers 1 lediglich verwaltend sind, und derselbe lediglich Zugriffsrechte der Benutzerdomäne 1 benö tigt, aber aufgrund seiner Benutzerdomänenmitgliedschaften die Zugriffsrechte für die Benutzerdomäne 2 und die Be nutzerdomäne 3 besitzt, was mehr Rechte sind, als für seine Arbeit nötigt ist.

Aufgrund der Zeit, die benötigt wird, um die notwendige Berechtigung beizubehalten, kann das Unterbewilligen einer Berechtigung wertvolle Zeit verbrauchen. Das Unterbewilligen einer Berechtigung kann dort auftreten, wo eine strenge Sicherheit vorhanden ist und einem Benutzer eine Berechti gung bedarfsmäßig bewilligt wird. Es wird beispielsweise angenommen, daß der Benutzer 1 der Benutzerdomäne 1 für einen Zugriff auf die Objektdomäne 1 zugewiesen ist, da derselbe regelmäßig die Rolle eines Verwaltungsarbeitnehmers einnimmt. Wenn der Benutzer 1 gelegentlich die Rolle einer Führungskraft (eines Managers) einnehmen muß, muß eine Zu griffsregel, die dem Benutzer 1 die Führungsberechtigung der Verwaltungsdomäne 2 bewilligt, erzeugt werden. Wenn der Be nutzer 1 gelegentlich die Rolle eines Operationsarbeits nehmers einnehmen muß, muß ähnlich eine Zugriffsregel für diesen Zweck erzeugt werden. Sobald die vorübergehende Zu weisung des Benutzers 1 entfernt wird, wird entweder Zeit benötigt, um die Zugriffsregel zu entfernen, oder das System ist einer Überbewilligung einer Berechtigung unterworfen.

Ein weiteres Problem des existierenden Modells der Benut zerzugriffssteuerung tritt auf, wenn dasselbe in mehreren Anwendungen auf der gleichen Plattform implementiert ist. Die Notwendigkeit einer Benutzerzugriffssteuerfunktionalität ist so groß, daß es bei Anwendungen als notwendig empfunden wurde, Sicherheitsmerkmale auf den Plattformen zu implemen tieren, auf denen die Anwendungen existieren. Es wird bei spielsweise angenommen, daß die Domäne 1 durch den Satz von Operationen {Lesen, Schreiben, Erzeugen} definiert ist, und die Plattform definiert die Führungspolitik (Management politik) {Benutzergruppe 1, Domäne 1, Lesen} dort, wo ein Mitglied der Benutzergruppe 1 einen Lesezugriff auf die Domäne 1 besitzt, und die Anwendung 1 definiert unabhängig die Führungspolitik {Benutzergruppe 1, Domäne 1, {Lesen, Schreiben}} dort, wo ein Mitglied der Benutzergruppe 1 einen Lese- und Schreib-Zugriff auf die Domäne 1 besitzt, wenn derselbe bei dieser Anwendung angemeldet ist. Das erste Pro blem besteht darin, daß ein Benutzer, der zu der Benutzer gruppe 1 gehört und der auf ein Objekt in der Domäne 1 zu greift, mit einem widersprüchlichen Berechtigungsbild zwi schen der Plattform und der Anwendung konfrontiert ist, da gemäß der Plattform der Benutzer einen Lesezugriff auf die Objekte der Domäne 1 besitzt, und der Benutzer in der Anwen dung einen Lese- und Schreib-Zugriff auf die gleichen Objek te besitzt. Außerdem stellt dieses Problem ein Problem für die Anwendungsintegration oder die Fähigkeit dar, daß zwei Anwendungen Objekte quer über die Domänen gemeinsam verwen den. Es kann beispielsweise, wenn die Anwendung 1 die glei che Führungspolitik wie die Plattform {Benutzergruppe 1, Do mäne 1, {Lesen}} definiert, eine Sicherheitslücke dort auf treten, wo ein Benutzer der Anwendung 1 keinen Schreibzu griff auf die Objekte der Domäne 1 haben sollte, denselben jedoch aufgrund einer Führungspolitik, die unabhängig für die Anwendung 2 erzeugt wird, besitzt. Als ein Resultat ist die Anwendungsintegration schwerer zu implementieren.

Die Aufgabe der vorliegenden Erfindung besteht darin eine Vorrichtung zum Steuern eines Benutzerzugriffs auf Compu terbasierte Objekte und ein Verfahren zum Steuern eines Be nutzerzugriffs auf Computer-basierte Objekte zu schaffen, die eine Berechtigung bewilligen können, die auf die spezielle Tätigkeit des Benutzers angepaßt ist, und eine An wendungswiderspruchsfreiheit und eine Anwendungsintegration fördern.

Diese Aufgabe wird durch eine Vorrichtung zum Steuern eines Benutzerzugriffs auf Computer-basierte Objekte gemäß An spruch 1 und ein Verfahren zum Steuern eines Benutzerzu griffs auf Computer-basierte Objekte gemäß Anspruch 21 ge löst.

Die vorliegende Erfindung verwendet das Konzept der Benut zerrollen, um einen flexibleren und leistungsvolleren Lösungsansatz der Benutzerzugriffssteuerung zu implementie ren. Dort wo ein Domänenmodell den Zugriff auf ein Objekt basierend auf Zugriffsrechten bestimmt, die der Benutzer zu einem oder mehreren Operationssätzen/Objektdomänen-Paarungen besitzt, bestimmt die vorliegende Erfindung einen Zugriff gemäß Rechten, die für eine oder mehrere Benutzerrollen de finiert sind, von denen der Benutzer ein Mitglied ist. Durch die gesamte Beschreibung hindurch ist ein "Benutzer" durch einen einzigartigen I. D. identifiziert, der für die Be nutzerbeglaubigung verwendet wird, und derselbe bezieht sich auf entweder eine Person oder einen Server, der Benutzer rollen für eine spezielle Anfrage vererbt. Ein Benutzer kann ein Mitglied von einer oder mehreren Benutzerrollen sein, und derselbe kann die Merkmale von einer oder mehreren Be nutzerrollen erben, wenn sich der Benutzer einloggt bzw. an meldet. Eine Benutzerrolle ist ein Satz von Handlungen, die durch einen Benutzer durchgeführt werden können, der ein Mitglied dieser Benutzerrolle ist. (Eine Benutzerrolle kann ferner durch andere Benutzerrollen definiert werden.) Eine Benutzerrolle gibt einem Benutzer Zugriffsrechte, die be stimmen, welche Handlungen zu einer Benutzerrolle gehören. Wenn sich ein Benutzer bei einer oder mehreren Benutzer rollen anmeldet, von denen derselbe ein Mitglied ist, be sitzt der Benutzer Zugriffsrechte zu den Handlungen dieser Benutzerrollen, die dem Benutzer die Berechtigung geben, diese Handlungen vorzunehmen. Ähnlicherweise kann ein Server Zugriffsrechte erhalten, indem derselbe anfangs einem Be nutzer zugeordnet ist oder die Identität des Benutzers für eine spezielle Anfrage erbt, so daß der Server als ein Fil ter für berechtigte Handlungen wirkt.

Das Implementieren der Benutzerzugriffssteuerung durch Be nutzerrollen verfeinert ferner die Ziele der leichten Füh rung und der Sicherheit in einer Netzumgebung. Allgemein fördert die Benutzerzugriffssteuerung diese Ziele, indem dieselbe die Unordnung reduziert und es Benutzern ermög licht, lediglich das zu betrachten, was sie für ihre Arbeit benötigen. Dies ist insbesondere dort wichtig, wo mehrere Anwendungen auf einer Plattform installiert sind, und wo eine stückchenweise Steuerung des Objektzugriffes zu einer Verwirrung, einem Fehler und einer Sicherheitslücke führen kann. Benutzerrollen eliminieren die Verwirrung, indem eine Führbarkeits/Sicherheits-Schicht injiziert wird, die die Handlungen steuert, die an Objekten durchgeführt werden können, die über mehrere Anwendungen hinweg gemeinsam ver wendet werden. Beispielsweise kann eine Benutzerrolle ver wendet werden, um Menüpunkte in einem verteilten System oder URLs (URL = Uniform Ressource Locator = Einheits-Ressourcen- Positionsanzeiger; eine Adresse für eine Ressource im Inter net) in einem Web-Browser (einer Netzsuchvorrichtung) auszu blenden. Da es Benutzerrollen ermöglichen, daß Zugriffsre geln insbesondere für die Verantwortlichkeiten eines Be nutzers in einer bestimmten Rolle erzeugt werden, ist ein dynamisches Rollenwechseln möglich, was die Probleme elimi niert, die dem Überbewilligen und Unterbewilligen einer Be rechtigung zugeordnet sind. Die Erfindung kann verwendet werden, um sicherzustellen, daß Benutzer widerspruchsfrei lediglich das durchführen können, für was sie über mehrere Anwendungen berechtigt: sind. Es ist weniger wahrscheinlich, daß ein Benutzer mit einem widersprüchlichen Bild einer Be rechtigung dort konfrontiert wird, wo die Berechtigungs erteilung durch eine einzige Steuerschicht und nicht durch mehrere Schichten implementiert ist. Zusätzlich wird durch Entfernen einer widersprüchlichen Berechtigungsanwendung die Anwendungsintegration durch eine widerspruchsfreie Zu griffs-Berechtigung oder -Verweigerung auf gemeinsam ver wendete Objekte unterstützt.

Bei einem ersten bevorzugten Ausführungsbeispiel der Erfin dung wird ein netzbasiertes Modell verwendet, um eine Be nutzerrollenzugriffssteuerung dort zu implementieren, wo es kein Konzept von Objekten und Domänen gibt. Bei einem zwei ten bevorzugten Ausführungsbeispiel der Erfindung stehen die Benutzerrollen mit Objekt- und Domänen-Konzepten in einer Wechselbeziehung, um die Benutzerrollenzugriffssteuerung zu implementieren. Bei beiden Ausführungsbeispielen kann die Benutzerrollenzugriffssteuerung auf zwei Arten verwendet werden: als Graphikbenutzerschnittstellen- (im folgenden GUI-) Filtern (GUI = Graphical User Interface) und als Lauf zeitzugriffsprüfen (Run-Time-Zugriffsprüfen) der ausgewähl ten Handlung. Beides ist durch die Zugriffsrechte der Be nutzerrollen definiert, die definieren, welche URLs oder Menüpunkte beispielsweise angezeigt und für einen Zugriff berechtigt sind.

Die Benutzerrollenzugriffssteuerung ist flexibler als das Zuordnenden von Zugriffsrechten zu entweder dem Objekt oder dem Benutzer, wie es in der Vergangenheit durchgeführt wur de. Das Zuordnen von Zugriffsrechten zu Objekten macht es schwer, eine Konfiguration zu modifizieren, wenn einem neuen Benutzer der Zugriff auf Objekte gegeben werden muß, insbe sondere, wenn es eine große Anzahl von Objekten gibt, und die neuen Rechte lediglich vorübergehend sind (z. B. wenn eine Person für einen Mitarbeiter eingesetzt wird). Das Zu ordnen von Rechten zu einem Benutzer kann insbesondere dann schwer beibehalten werden, wenn neue Objekte hinzugefügt werden (da sich dieselben häufig in einer dynamischen Netz umgebung befinden) und Benutzer Zugriffsrechte basierend auf unterschiedlichen Rollen, die dieselben spielen müssen (mög licherweise vorübergehend, um für jemanden einzuspringen, der krank oder im Urlaub ist), ändern müssen. Die Benutzer rollenzugriffssteuerung sieht die höchste Flexibilität und die geringste Konfigurationskomplexitäts- und Mehraufwands- Menge vor. Bei dem zweiten bevorzugten Ausführungsbeispiel beeinflußt das Ändern der Definition einer Domäne (d. h. durch Hinzufügen von neuen Objekten) alle Benutzerrollen, die eine Zugriffsregel für diese Domäne umfassen. Das Ändern der Definition eines Operationssatzes (d. h. durch Hinzufü gen von neuen Operationen, da eine neue Anwendung gerade installiert wurde) beeinflußt alle Benutzerrollen, die eine Zugriffsregel für diesen Operationssatz umfassen. Das Ändern der Definition einer Benutzerrolle (durch Hinzufügen oder Entfernen einer Zugriffsregel) ändert die Zugriffsrechte für alle Benutzer, die dieser Benutzerrolle zugewiesen sind. Es besteht keine Notwendigkeit, die Zugriffsrechte für jeden betroffenen Benutzer zu aktualisieren. Außerdem erleichtert es die Benutzerrollenzugriffssteuerung Zugriffsrechte Be nutzern in großen gut definierten Gruppierungen zu bewilli gen oder zu verweigern. Beispielsweise können einem Benutzer "Netzbetreiber"-Rechte gegeben werden, indem dem Benutzer die "Netzbetreiber"-Benutzerrolle zugewiesen wird, statt daß dem Benutzer eine große Anzahl von einzelnen Zugriffsrechten für verschiedene Operationen in verschiedenen Objekten zuge wiesen wird.

Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend unter Bezugnahme auf die beigefügten Zeichnungen näher erläutert. Es zeigen:

Fig. 1 das Domänenmodell der Benutzerzugriffssteuerung;

Fig. 2 das Benutzerrollenmodell der Zugriffssteuerung, das in der vorliegenden Erfindung ausgeführt ist;

Fig. 3 Komponenten, die bei einer Sitzungsanmeldung be troffen sind;

Fig. 4 eine Beispielsdefinition einer Java-Klasse zum Zu greifen auf Sitzungseigenschaften;

Fig. 5 eine Beispielsdefinition einer C-APT zum Zugreifen auf Sitzungseigenschaften;

Fig. 6 eine Beispielsstarterregistrierungsdatei;

Fig. 7 Komponenten, die bei der Benutzerrollenzugriffs steuerung betroffen sind, die in einem Web-Browser implementiert ist, indem die graphische Benutzer schnittstelle durch eine Starterinitialisierung gefiltert wird;

Fig. 8 Komponenten, die bei der Benutzerrollenzugriffs steuerung betroffen sind, die in einem Web-Browser durch ein Laufzeitzugriffsprüfen implementiert ist, wenn ein URL unter Verwendung der ovlaunch-Kompo nente ausgeführt wird;

Fig. 9 Komponenten, die bei der Benutzerrollenzugriffs steuerung in einem Web-Browser betroffen sind, der durch ein Laufzeitzugriffsprüfen implementiert ist, wenn ein URL ohne die ovlaunch-Komponente ausge führt wird;

Fig. 10 eine Beispielssicherheitskonfiguration für ein zweites bevorzugtes Ausführungsbeispiel; und

Fig. 11 ein Beispielssicherheitsmodell für ein zweites be vorzugtes Ausführungsbeispiel.

Die vorliegende Erfindung ist ein Verfahren und eine Vor richtung zum Implementieren der Benutzerzugriffssteuerung durch Benutzerrollen. Durch die gesamte Beschreibung bezieht sich ein "Benutzer" entweder auf eine Person oder einen Ser ver, der Benutzerrollen für eine spezielle Anfrage vererbt. Ein Benutzer ist durch einen einzigartigen ID identifiziert, der für die Benutzerbeglaubigung benutzt wird. Eine Benut zerrolle ist ein Satz von Handlungen, der bestimmt, was die Funktion eines Benutzers ist. Dieselbe kann den Bereich einer Betriebsverantwortung definieren, wie z. B. als Si cherheitsverwalter, als Netzverwalter oder als Systemverwal ter. Die Benutzerrollenzugriffssteuerung kann in einem oder mehreren Computer-lesbaren Speichermedien 232 (Fig. 2) und Programmcode, der auf dem einen oder den mehreren Computer lesbaren Speichermedien 232 zum Erzeugen von einer oder mehreren Benutzerrollen 200, 202, 204 liegt, ausgeführt sein, wobei jede der einen oder der mehreren Benutzerrollen 200, 202, 204 einen Satz von Zugriffsrechten 226, 228, 230 aufweist, der einem Satz von Benutzern zugeordnet ist, und jedes der Zugriffsrechte 226, 228, 230 Handlungen 206, 208, 210, 212, 214, 216, 218, 220, 222 darlegt, die durch einen Benutzer in dem Satz von Benutzern an einen Satz von Compu terbasierten Objekten durchgeführt werden können. Die Be nutzerrollenzugriffssteuerung kann ferner in einem verfah ren, um den Benutzerzugriff zu steuern, ausgeführt sein, das das Empfangen einer Anfrage von einem Benutzer, um eine Handlung während einer Computersitzung durchzuführen, und das Wiedergewinnen ansprechend auf die Anfrage von einer oder mehreren Benutzerrollen 200, 202, 204, von denen der Benutzer für die Sitzung ein Mitglied ist, wobei jede der einen oder mehreren Benutzerrollen 200, 202, 204 eines oder mehrere Zugriffsrechte 226, 228, 230 bestimmt, die der Be nutzer für die Sitzung besitzt, und wobei das eine oder die mehreren Zugriffsrechte 226, 228, 230 eine oder mehrere Handlungen 206, 208, 210, 212, 214, 216, 218, 220, 222 be stimmen, die der Benutzer während der Sitzung durchführen kann, und das Bestimmen aufweist, ob der Benutzer berechtigt ist, die angefragte Handlung durchzuführen, indem bestimmt wird, ob eine oder mehrere Benutzerrollen 200, 202, 204, von denen der Benutzer ein Mitglied ist, ein Zugriffsrecht 226, 228, 230 aufweisen, das die angefragte Handlung erlaubt.

Fig. 1 stellt das Domänenmodell für die Benutzerzugriffs steuerung dar, bei dem die Zugriffsrechte des Benutzers durch eine oder mehrere Paarungen eines Operationssatzes 100, 102, 104 zu einer Objektdomäne 106, 108, 110 bestimmt sind. Bei diesem Modell ist ein Benutzer zu einer Handlung an einem Objekt berechtigt, wenn dem Benutzer ein Zugriffs recht zugewiesen ist, das eine Paarung eines Operations satzes definiert, der die angefragte Handlung zu einer Ob jektdomäne enthält, die das angefragte Objekt enthält.

Fig. 2 stellt ein Ausführungsbeispiel der vorliegenden Er findung, eine Benutzerrollenzugriffssteuerung, dar, bei der die spezielle Anfrage eines Benutzers berechtigt ist, wenn der Benutzer ein Mitglied von einer oder mehreren Benutzer rollen 200, 202, 204 ist, die eines oder mehrere Zugriffs rechte 226, 228, 230 zu einer oder mehreren Handlungen 206, 208, 210, 212, 214, 216, 218, 220, 222 enthalten, wobei min destens ein Zugriffsrecht die angefragte Handlung umfaßt. Mit anderen Worten ist eine Handlung berechtigt, wenn der Benutzer einer Benutzerrolle zugeordnet ist, die mindestens ein Zugriffsrecht zu der angefragten Handlung enthält.

Bei einem ersten bevorzugten Ausführungsbeispiel der Erfin dung ist die Benutzerrollenzugriffssteuerung in einer netz basierten Umgebung implementiert, um einen Benutzer zu be rechtigen oder ihm zu verweigern, eine Handlung aufzurufen, wobei ein URL die Zugriffsrechte eines Benutzers zu einer speziellen Handlung bestimmt. Dieses Ausführungsbeispiel ist ein Web-Browser (Netz-Suchvorrichtung) und eine Web- Ser ver-unabhängige (Netz-Server-unabhängige) Vorrichtung für ein netzbasiertes Benutzerrollenmodell. Die netzbasierte Benutzerrollenzugriffssteuerung ist in einer Netzanwendung implementiert, auf die hierin als der Starter (Launcher) Bezug genommen wird, die dem Benutzer Handlungen durch die URLs zur Verfügung stellt.

Ein Aspekt der Erfindung besteht darin, daß die Benutzerrol lenzugriffssteuerung auf die Anzeige eines Starterfensters (Launcher-Fensters) angewendet wird, um die GUI auf Handlun gen zu filtern, die für die aktiven Benutzerrollen definiert sind. Ein Benutzer ist zu einem URL berechtigt und kann je den beliebigen auf der Anzeige verfügbaren URL auswählen. Ein weiterer Aspekt der Erfindung besteht darin, daß die Be nutzerrollenzugriffssteuerung für ein Laufzeitzugriffsprüfen verwendet wird, bei dem ein Benutzer berechtigt ist, eine Handlung durchzuführen, wenn der URL für die Handlung für die eine oder die mehreren Benutzerrollen für die Sitzung des Benutzers definiert ist.

Benutzeranmeldung und Sitzungsinitialisierung

Um beglaubigt zu werden und die Berechtigung zu erhalten, die Zugriffsrechte anzunehmen, die durch eine oder mehrere Benutzerrollen definiert sind, muß der Benutzer eine Netz sitzung (Web-Sitzung) starten. Eine Sitzung ist eine Gruppe von Anwendungen, die einem speziellen Benutzer auf einer speziellen Anzeige zugeordnet sind. Alle Anwendungen, die direkt oder indirekt von einem Starterfenster (d. h. der GUI auf der obersten Ebene für die Netzsitzung) gestartet wer den, sind Teil einer Sitzung, und können gemeinsam Informa tionen verwenden. Es ist erforderlich, daß sich ein Benutzer durch eine Anmeldeprozedur immer dann anmeldet, wenn eine Netzsitzung nicht existiert. Dies kann entweder dann passie ren, wenn noch keine Anmeldung für einen gegebenen Web- Browser-Prozeß (Netz-Suchvorrichtungs-Prozeß) durchgeführt wurde, oder wenn die Netzsitzung aufgrund einer konfigurier baren Aktivitätszeitdauer abgelaufen ist. Teil des Zustands einer Netzsitzung ist die Identität (der Benutzername) des Benutzers und eine Liste von Benutzerrollen, die definieren, zu was der Benutzer berechtigt ist. Sobald eine Netzsitzung erzeugt wird, kann der Benutzer frei auf URLs zugreifen, die durch die Benutzerrollen für die Sitzung erlaubt sind. Die Benutzerrollen sind die aktiven Benutzerrollen des Be nutzers. Diese aktiven Benutzerrollen bestimmen, welche Art von Benutzerschnittstelle der Benutzer hinsichtlich dessen sieht, welche URLs angezeigt werden. Dieselben bestimmen ferner, welche Laufzeit-URLs der Benutzer aufrufen kann. Bei diesem Ausführungsbeispiel nimmt ein Benutzer alle Benutzer rollen an, von denen derselbe ein Mitglied ist, wobei alle Benutzerrollen für den Benutzer aktiv sind. Die Erfindung umfaßt ferner das Konzept, dem Benutzer zu ermöglichen, aus zuwählen, welche Benutzerrollen aktiv sind, und welche Be nutzerrollen inaktiv sind, um die Rechte dieser Person zu begrenzen oder zu erweitern.

In Fig. 3 startet ein Benutzer eine Sitzung, indem derselbe den URL für den Starter in einen Web-Browser 300 eingibt.

Der URL für den Starter (Launcher) wird als http:://host name/OvCgi/ovlaunch.exe aufgerufen, der ein URL-Argument akzeptieren kann, das automatisch ausgeführt werden kann, wenn eine Sitzung beginnt, die Zugriffsrechten unterworfen ist. (Wenn kein URL für ovlaunch spezifiziert ist, wird ein Standardstarterfenster nach der Anmeldung angezeigt, in dem ein Benutzer einen URL durch den Starter oder durch einen Web-Browser aufrufen kann.) Die URL-Anfrage für den Starter wird zu einem Web-Server 302 durch ein Dient/Server-Proto koll übertragen, das verwendet wird, um auf Informationen in dem weltweiten Netz (World Wide Web) zuzugreifen. Dieses Protokoll wird ein Hypertext-Übertragungsprotokoll (im fol genden HTTP; HTTP = Hypertext Transfer Protocol) genannt. Der Web-Server ruft das CGI- (CGI = Common Gateway Interface = Allgemeine Netzübergangsschnittstelle) Programm ovlaunch 308 auf 306, das einen HTML-Anmeldebildschirm darstellt und den Benutzer auffordert, einen Benutzernamen und ein Paßwort einzugeben. Der Bildschirm wird zu dem Web-Server zurückge leitet 338.

Der Web-Server liest den Bildschirm und ruft 310 ovlogin (ovAnmeldung) 312 auf, das den Benutzernamen und das Paß wort, die durch den Benutzer eingegeben werden, einreicht, um zu bestimmen, ob es eine Sitzung für diesen Browser (Suchvorrichtung) gibt. Dies wird durchgeführt, indem ge prüft wird, ob ein Browser-Cookie (Browser-Plätzchen), das ovWebSession (ovNetzSitzung) genannt wird (das detaillierter im folgenden erörtert ist) eingestellt wurde. Wenn dieses Cookie eingestellt ist, wird eine Nachricht zurückgegeben, die anzeigt, daß der Benutzer bereits angemeldet ist, und ovlogin erhält eine Sitzungsnummer von dem Cookie, um die selbe zum Verifizieren der Sitzung mit dem ovsessionmgr (ovSitzungsFührung) zu verwenden. Wenn kein Cookie einge stellt ist, fragt ovlogin eine neue Sitzung an. In beiden Fällen versucht ovlogin sich mit ovsessionmgr 316 zu verbin den 314, das als ein Server für die. Sitzungsinformationen dient. Sobald eine Verbindung mit dem ovsessionmgr herge stellt ist, verifiziert ovlogin entweder die existierende Sitzung, indem die Cookie-Sitzungsnummer eingereicht wird 318, oder fragt eine neue Sitzung an, indem sowohl der Be nutzername und das Paßwort als auch die Fern-IP-Adresse (Re mote-IP-Address), wie durch die aktuelle Umgebung bestimmt, bei dem ovsessionmgr eingereicht werden.

Wenn der Benutzername und das Paßwort nicht gültig sind, leitet der ovsessionmgr diese Information zu ovlogin weiter 328, das dieselben zu dem Web-Server sendet 340. Die Anmel deseite wird durch eine Fehleranzeige ersetzt, die durch den Netz-Browser empfangen und dann angezeigt wird. Wenn der Benutzername und das Paßwort gültig sind und die existie rende Sitzung verifiziert ist, sendet 328 das ovsessionmgr eine Nachricht zurück zu ovlogin, das eine Nachricht zurück 340 zu dem Web-Server und dann zu 304 dem Web-Browser sen det, die anzeigt, daß der Benutzer bereits angemeldet ist. Wenn der Benutzername und das Paßwort gültig sind und eine neue Sitzung angefragt wird, sendet 328 das ovsessionmgr eine Nachricht zu ovlogin, das eine Nachricht zurück zu dem Web-Server sendet 340 und dann zu dem Web-Browser sendet 304, die anzeigt, daß die Anmeldung erfolgreich ist.

Wenn die Anmeldung erfolgreich ist, liest das ovsessionmgr die Sitzungskonfigurationsdatei 320, die globale Sitzungs informationen enthält. Das ovsessionmgr empfängt 321 Werte für die folgenden Felder:

- Benutzeranmeldung: ermöglicht es, daß eine Sitzung mit oder ohne eine Benutzerbeglaubigung erzeugt wird. Die Werte sind Ein/Aus. Der Standardwert bzw. Vorgabewert ist Aus.
- Anmeldungsprotokollieren: protokolliert erfolgreiche und fehlgeschlagene Anmeldungsversuche. Die Werte sind Ein/Aus. Der Vorgabewert ist Aus.
- Zugriffsprotokollieren: protokolliert URLs, auf die er folgreich zugegriffen wird. Die Werte sind Ein/Aus. Der Vorgabewert ist Aus.
- Sitzungszeitüberschreitung: spezifiziert den Zeitbetrag in Stunden, in dem eine Sitzung abläuft. Die Werte sind Ganzzahlen, die größer als 0 sind. Der Vorgabewert ist 9.

Wenn einer dieser Werte sich seit der letzten Sitzung geän dert hat, aktualisiert das ovsessionmgr die inneren Konfigu rationswerte desselben. Wenn die Benutzeranmeldung aus ist, wird eine Sitzung ohne eine weitere Beglaubigung erzeugt. Wenn die Benutzeranmeldung ein ist, beglaubigt ovsessionmgr den Benutzer, indem die Benutzerpaßwortdatei 322 gelesen wird, die ein Behälter von verschlüsselten Benutzerpaßwör tern ist, der durch einen Verwalter eingestellt wird und durch das Programm htpasswd (htPaßwort) 324 gespeichert wird 323. Die Benutzerpaßwortdatei besitzt das folgende Format: banana: FXDFRAxjRkuFA, wobei der erste Wert der Benutzername und der zweite Wert das verschlüsselte Paßwort ist.

Wenn das Paßwort, das durch die Benutzerpaßwortdatei zu rückgegeben 325 wird, mit dem eingegebenen Benutzerpaßwort übereinstimmt, wird der Benutzer beglaubigt, eine Sitzung wird erzeugt und die folgenden Sitzungsinformationen werden mit ovsessionmgr gespeichert:

- der Benutzername
- das Paßwort: das Paßwort wird in einer "zersetzten" (d. h. ein logisches XOR wird bei jedem Buchstaben durchge führt) Art gespeichert, so daß es nicht möglich ist, dasselbe in Klartext durch Lesen des Verarbeitungsspei chers zu sehen.
- Benutzerrollen: ovsessionmgr erhält diese Informationen durch Lesen der Datei htpgroup (htp-Gruppe) 326, die spezifiziert, welche Benutzer zu welchen Benutzerrollen gehören, wobei jeder Benutzer zu einer oder mehreren Benutzerrollen gehören kann. Die Benutzerrollendatei besitzt das folgende Format: Meine-Benutzer: pumpkin peanuts almonds walnuts, wobei der erste Wert die Be nutzerrolle und die folgenden Werte die Benutzer sind, die zu dieser Benutzergruppe gehören. Die Benutzer rollendatei gibt alle Benutzerrollen zu ovsessionmgr zurück 324, in denen der aktuelle Benutzer ein Mitglied ist, so daß einem Benutzer alle Zugriffsrechte für alle Benutzerrollen des Benutzers bewilligt werden. Die Er findung kann es ferner ermöglichen, daß sich ein Be nutzer in einer Benutzerrolle anmeldet und zwischen Rollen wechselt; und
- die Fern-IP-Adresse: diese wird für eine zusätzliche Gültigkeitsprüfung des Anrufers basierend auf der Sit zungsnummer verwendet.

Die Netzanwendungen, die zu einer Netzsitzung gehören, (d. h. die in dem Zusammenhang einer Netzsitzung gestartet wer den) besitzen einen Zugriff zu den Sicherheits- und Zu griffs-Steuerinformationen für den aktuellen Benutzer. (Netzanwendungen können beispielsweise Java-Applets und CGI-Programme sein.) Diese Informationen werden den Netzan wendungen durch Sitzungseigenschaften zur Verfügung ge stellt, auf die durch eine Anwendung, die zu der Netzsitzung gehört, durch die Anwendungsprogrammierschnittstellen (im folgenden API; API Application Programming Interface) zugegriffen werden kann. Fig. 4 ist eine Beispielsdefinition einer Java-Klasse zum Zugreifen auf Sitzungseigenschaften, und Fig. 5 ist eine Beispielsdefinition einer C-API zum Zugreifen auf Sitzungseigenschaften. In Fig. 4 wird eine Sitzung eingeleitet 400 und ein Sitzungs-ID für die aktuelle Sitzung wird von dem Starter erhalten 406. Wenn die Sitzung nicht gültig ist (d. h. der Benutzer nicht beglaubigt ist), kann das Java-Applet enden oder eine andere geeignete Hand lung 402 vornehmen. Sobald eine Sitzung gestartet ist, kann das Java-Applet den Anmeldenamen des Benutzers 408 erhalten, wenn die Anmeldung aktiviert ist 404. Dasselbe kann eine Li ste von Benutzerrollen 410 für diesen Benutzer solange wie dergewinnen, bis die Anmeldung deaktiviert wird. Dieses Ja va-Applet kann ferner das Laufzeitzugriffsprüfen 412 imple mentieren, das eine feinkörnigere Zugriffssteuerung ermög licht, als es durch die GUI sichtbar sein kann. In Fig. 5 prüft ein CGI-Programm, ob der Benutzer bereits angemeldet ist, wenn die Variable Abgesichert wahr ist 500. Wenn der Benutzer derzeit nicht angemeldet ist, wird das Aufrufen von OVwwwInit, wobei das Argument Abgesichert auf WAHR einge stellt ist, dazu führen, daß dem Benutzer die Anmeldeseite gezeigt wird. Nachdem sich der Benutzer erfolgreich angemel det hat, wird das CGI-Programm neu aufgerufen. Wie das Java-Applet in Fig. 4, kann das CGI-Programm beenden oder eine andere geeignete Handlung vornehmen, wenn die Sitzung nicht gültig 502 ist. Wenn die Sitzung gültig ist, wird ein Sitzungs-ID erhalten 504. Die CGI wird den Namen des Be nutzer 508 wiedergewinnen, wenn die Anmeldung aktiviert ist 406. Dieselbe kann ferner die Rollen des Benutzers 510 wie dergewinnen und überprüfen, ob der Benutzer zu einer speziellen Rolle 512 gehört. Diese CGI kann ferner ein Lauf zeitzugriffsprüfen implementieren 514.

Bezugnehmend zurück auf Fig. 3 wird, wenn die Sitzungseigen schaft Anmeldungsprotokollieren aktiv ist, eine Anmeldungs nachricht zu der Anmeldungsprotokolldatei 332 geschrieben 330. Wenn eine neue Sitzung erzeugt wird, gibt ovsessionmgr 328 eine zufällig erzeugte Sitzungsnummer zu ovlogin zurück und erzeugt das Browser-Cookie OvWebSession (OvNetzSizung), das als ein Ausweis dafür dient, daß sich der Benutzer ange meldet hat. Das Cookie läuft ab, und die Sitzung endet, wenn der Benutzer den Browser verläßt, oder wenn die Sitzung nach einer konfigurierbaren Zeitdauer fehlender Aktivität ab läuft. Sobald ovsessionmgr die Sitzungsnummer in dem Browser-Cookie OvWebSession für eine spätere Gültigkeits prüfung der Sitzung (dieses Cookie wird durch ovlogin ver wendet, um nach einer existierenden Sitzung zu prüfen) speichert, kann ein Benutzer eine Handlung durch Ausführen eines URL durchführen.

Ein URL kann durch Auswählen des URL aus einem Starterfen ster ausgeführt werden, das ein URL-Argument zu dem Starter liefert, so daß derselbe automatisch bei der Benutzeranmel dung ausgeführt wird, oder der URL kann direkt von einem Web-Browser aufgerufen werden. Zugriffsrechte bei dem ersten Verfahren zum Ausführen eines URL werden bei der Starterini tialisierung definiert, bei der eine Benutzerrollenzugriffs steuerung durch Filtern der GUI auf jene URLs, die durch die Rollen des Benutzers berechtigt sind, implementiert ist. Die Zugriffsrechte bei den letzteren zwei Verfahren werden bei der URL-Ausführung definiert, bei der die Benutzerrollenzu griffssteuerung durch ein Laufzeitzugriffsprüfen implemen tiert ist.

Starterinitialisierung und GUI-Filtern

Das Vorgabeverhalten bei der Ausführung des ovlaunch-CGI- Programms (nach der Anmeldungsprozedur) besteht darin, daß dasselbe ein. Starterfenster öffnet. (Das Vorgabeverhalten bezieht sich auf das Anfragen des CGI-Programms ovlaunch ohne ein URL-Argument.) Ein Starterfenster ist eine GUI, die dem Benutzer die gesamae Funktionalität zur Verfügung stel len kann, die durch die Benutzerrollen für die aktuelle Sitzung ermöglicht sind. Ein Starterfenster ist lediglich einer von vielen Wegen zum Darstellen der für den Benutzer durch die Benutzerrollenkonfiguration möglichen Operationen. Die allgemeine Idee besteht darin, daß die GUI das Filtern durchführt, um dem Benutzer lediglich jene Handlungen zu zeigen, für die der Benutzer berechtigt ist.

Ein Starterfenster ist ein Java-Applet, das eine Anzeige einer Führungsfunktionalität (d. h. Handlungen) basierend auf Benutzerrollen und das Starten dieser Funktionalität durch URLs liefern kann. Ein Starterfenster ist in zwei Tei le geteilt, wobei die Inhalte desselben von dem Starterre gistrierungsdateien erhalten werden: Führungsfunktionalität und aktive Hilfe. Der Führungsfunktionalitätsbereich enthält einen Satz von Etiketten (Tabs), die Kategorien von Führungsoperationen anzeigen. Jede Kategorie wird durch ein kleines Icon angezeigt. Die Liste der Kategorien kann bei spielsweise Aufgaben, Werkzeuge, Objektansichten, den Führungsbereich und Hilfe umfassen. Innerhalb jeder Katego rie gibt es eine hierarchische (Baumlisten-) Darstellung der relevanten Operationen. Die Inhalte dieser Baumlisten sind durch (1) die Benutzerrollen des Benutzers; und (2) den Ort der Startersitzung bestimmt. Die Benutzerrollen, für die der Benutzer konfiguriert ist (alle kombiniert) bestimmen die Handlungen, die in dem Starterfenster erscheinen, obwohl es für den Benutzer ferner möglich ist, einen Teilsatz von Rollen auszuwählen. Der Benutzer navigiert durch die Baum liste unter Verwendung einer Standardeinrichtung zum Öffnen und Schließen von Behälterknoten. Ein einziger Klick auf einen Behälterknoten erweitert den Knotenpunkt. Ein einziger Klick auf einen Behälterknoten startet die zugeordnete Hand lung, die darin bestehen kann, einen URL auszuführen. Wenn eine Starterkategorie leer ist (d. h. es gibt keine Listen objekte in derselben) wird die Kategorie dem Benutzer nicht gezeigt. Wenn ein Starterbehältereintrag leer ist, wird der Behältereintrag nicht angezeigt. (Dies ist ähnlich zu leeren Menükaskaden. Es wird kein Menüschrumpfen durchgeführt, wenn es lediglich ein Objekt unter dem Behälter gibt.) Der Be reich der aktiven Hilfe zeigt eine kurze Hilfenachricht an, die die Funktion dieser Operation erklärt, über der der Cur sor plaziert ist.

Die Handlungen, die in dem Starterfenster angezeigt werden, sind von den aktiven Benutzerrollen für die Sitzung ab hängig. Benutzerrollen werden durch die Starterregistrie rungsdateien, die normalerweise durch Entwickler vorgesehen werden, jedoch durch einen Verwalter modifiziert oder er gänzt werden können, konfiguriert. Die Starterregistrie rungsdateien weisen folgende Merkmale auf:

- Anwendungsinformationen, die einen Anzeigezeichensatz, die Version, das Urheberrecht und die Beschreibung auf weisen. Obwohl diese Informationen nicht durch den Starter angezeigt werden, wird dieser Block lediglich verwendet, um nützliche Informationen in der Starter registerierungsdatei zu liefern.
- Der Etikettblock (Tab-Block) ermöglicht es, daß ein optionaler Icondateiname auf dem Etikett angezeigt wird, das die Listengegenstandseinträge enthält. Dieser Block enthält ferner einen optionalen aktiven Hilfe text, der dargestellt wird, wenn der Benutzer das Eti kett auswählt.
- Der Listenblock weist Listengegenstandseinträge auf. Die Komponenten der Listengegenstände umfassen einen Vorrangwert, einen Listengegenstandsnamen, das Icon, die aktive Hilfe und Funktionen. Zwei mögliche Funktio nen sind: eine Handlungsfunktion, die einen Endlisten gegenstand anzeigt, der zu einem Handlungsblock zeigt, der die Handlungsdefinition aufweist; und eine Listen funktion, die ein Komponentenlistenobjekt anzeigt, das zu einem Listenblock zeigt, um eine Definition einer hierarchischen Baumliste zu ermöglichen.
- Der Handlungsblock umfaßt mehrere Anweisungen.
- Eine URL-Anweisung, die einen URL enthält, um die Handlung zu starten.
- Eine Zugriffsanweisung, die aufgelistet wird und die eine Liste der Benutzerrollen ist, die einen Zugriff auf diese Handlung besitzen. Wenn die Zu griffsanweisung nicht vorhanden ist, können alle gültigen Benutzer auf die Handlung zugreifen. Der Schlüssel zu der Benutzerrollenzugriffssteuerung ist in dieser Anweisung definiert.
- Eine Netzfensteranweisung, die die Charakteristika des Fensters,, in das der URL geladen wird, spezifi ziert.

Fig. 6 ist eine Beispielsstarterregistrierungsdatei, die An wendungsinformationen 600, einen Etikettblock (Tab-Block) 602, der einen Listengegenstandeintrag definiert, und zwei Icons mit aktiver Hilfe, einen Listenblock 604, der einen Listeneintrag enthält, der zu einem Handlungsblock zeigt, und zwei Handlungsblöcke 606(a), 606(b) enthält, die jeweils den URL, der für diese Handlung aufgerufen wird, und die Be nutzerrollen, die berechtigt sind, um diese Handlung durch zuführen, enthalten.

Die Benutzerrollenzugriffssteuerung in einem Web-Browser, die durch das GUI-Filtern während der Starterzeitinitia lisierung implementiert wird, ist in Fig. 7 dargestellt. Ein Benutzer ruft den ovlaunch-URL durch einen Web-Browser 300 auf, der eine Anfrage zu dem Web-Server 302 sendet 304. Der Web-Server 302 ruft das ovlaunchreg (ovstartreg) 702 auf 700, um Registrierungsinformationen aus den Starterregi strierungsdateien 706 wiederzugewinnen 704. Das ovlaunchreg gewinnt dann Sitzungsinformationen (d. h. Benutzer und Be nutzerrollen) aus Informationen wieder 708, die mit dem ovsessionmgr 316 gespeichert sind. Das Ovlaunchreg ruft eine Analysebibliothek auf, um die Registerierungsinformationen zu analysieren und basierend auf den Benutzerrollen, für die der Benutzer berechtigt ist, zu filtern. Ein Eintrag wird zu dem Web-Server 302, dem Web-Browser 300 bzw. einem Starter fenster 714 zurückgegeben 710, 304, 712, wenn die zugeordne te Handlung desselben eine Handlung ist, für die der Be nutzer berechtigt ist. Mehrere Baumlisten werden in dem Starterfenster jeweils in einem etikettierten bzw. ta bellierten Feld aufgebaut. Als ein Resultat besitzt der Benutzer einen Zugriff zu einem beliebigen URL, der in dem Starterfenster zur Verfügung gestellt wird, da der Benutzer lediglich das sieht, für was er berechtigt ist.

Handlungsaufruf und Laufzeitzugriffsprüfen

Zusätzlich zu dem GUI-Filtern der für den Benutzer relevan ten Operationen ist die Zugriffssteuerung ferner durch ein Laufzeitzugriffsprüfen implementiert, wenn ein Benutzer tat sächlich eine Handlung aufruft. Ein Benutzer kann eine Hand lung durch die Verwendung des CGI-Programms ovlaunch, wie es durch die ersten zwei Verfahren im folgenden dargestellt ist, oder ohne ovlaunch aufrufen, wie es durch das letzte Verfahren im folgenden dargestellt ist.

Ein Verfahren, mit dem ein Benutzer eine Handlung aufrufen kann, besteht darin, auf einen Gegenstand in dem Starter fenster zu klicken, der einem URL und der zugeordneten Hand lung desselben entspricht. Das Laufzeitzugriffsprüfen kann bei diesem Szenario implementiert werden, wenn das GUI-Fil tern nicht implementiert ist, oder kann sogar als eine zu sätzliche Sicherheitsschicht implementiert werden. Das Auf rufen einer Handlung führt zu dem Aufrufen des ovlaunch- CGI-Programms mit dem URL der angeforderten Handlung als Argument. Das ovlaunch-CGI-Programm verwendet die C-Netz- Sitzung-API, um mit dem Programm ovsessionmgr zu sprechen, um zu verifizieren, ob es eine gültige Sitzung gibt. Das selbe kann ferner den API-Ruf verwenden, um zu verifizieren, ob es dem Benutzer erlaubt ist, die spezielle Handlung basierend auf der aktiven Benutzerrolle für die Sitzung aus zuführen.

Ein weiteres Verfahren für den Benutzer, um eine Handlung aufzurufen, besteht darin, den Web-Browser zu verwenden, um den URL für das ovlaunch mit einem URL-Argument (z. B. http://OvCgi/ovlaunch.exe?URL = http://some/path) auf zurufen. Das Ovlaunch wird dann die angefragte Handlung starten, die durch den URL spezifiziert ist, der den Zu griffsrechten des Benutzers für die Sitzung unterworfen ist. Dies ist zum Erhalten eines Zugriffs zu einer Handlung nütz lich, die als eine Lesezeichen (Bookmark) gesichert ist.

Dieses Verhalten kann ferner verwendet werden, um eine "alternative Konsole" anstelle des Starterfensters zu star ten.

Schließlich kann ein Benutzer eine Handlung aufrufen, indem derselbe den zugeordneten URL desselben direkt aus dem Web- Browser (ohne die Verwendung des eingreifenden ovlaunch- CGI-Programms) aufruft. Da dies eine potentielle "Hinter tür"-Einrichtung zum Zugreifen auf eine beschränkte Funktio nalität bildet, sind zusätzliche Sicherheitseinrichtungen erforderlich. Zuerst können HTML-Dokumente in einem spe ziellen "geschützten" Verzeichnis plaziert sein, das nicht konfiguriert ist, um für den Web-Browser sichtbar zu sein. Ein Zugriff zu diesen HTML-Dokumenten ist dann lediglich möglich, indem dieselben als ein URL-Argument zu dem ov launch-CGI-Programm angefordert werden, das das "geschützte" Verzeichnis nach HTML-Dokumenten überprüft und dieselben zurückgibt, wenn der Benutzer die geeigneten Zugriffsrechte besitzt. Die HTML-Dokumente in dem "geschützten" Verzeichnis können nicht wiedergewonnen werden, indem dieselben direkt angefordert werden. Zweitens können Netz-Anwendungen (bei diesem Ausführungsbeispiel CGI-Programme und Java-Applets) die Netz-Sitzungs-APIs verwenden, um ein Laufzeitzugriffs prüfen durchzuführen. Diese Programme können prüfen, um si cherzustellen, daß es eine Sitzung gibt (d. h. daß sich der Benutzer angemeldet hat und berechtigt ist) und daß sich die Handlung, die angefordert wird, in der Benutzerrolle für den aktuellen Benutzer befindet. Wenn der Benutzer keine Erlaub nis für die Handlung besitzt, die durch die Netz-Anwendung dargestellt ist, können dieselben enden bzw. aussteigen oder eine andere geeignete Handlung durchführen.

Obwohl der Benutzer möglicherweise das ovlaunch-CGI-Programm umgehen kann, ist es aus mehreren Gründen notwendig. Erstens besitzt ein ovlaunch-CGI-Programm andere Rollen, die sich nicht auf die Sicherheit beziehen, wie z. B. das Erzeugen eines Kunden-Web-Browser-Fensters, in dem ein URL auszu führen ist. Zweitens stellt ovlaunch einen sicheren Zugriff auf HTML-Dokumente in dem "geschützten" Verzeichnis sicher. Drittens liefert ovlaunch ein bestimmtes Zugriffsebene für Netz-Anwendungen, die nicht modifiziert wurden, um die Netz-Sitzungs-APIs zu verwenden. Dies ist insbesondere wahr, wenn der Benutzer nicht den URL zum Aufrufen der Handlung kennt. Dies erleichtert es, existierende Netz-Anwendungen zu integrieren. Für ein höheres Sicherheitsniveau ist es jedoch bei Netz-Anwendungen notwendig, die Netz-Sitzungs-APIs zu verwenden, die sich auf die Benutzerrollensicherheit be ziehen.

Fig. 8 stellt die Benutzerrollenzugriffssteuerung in einem Web-Browser, die durch ein Laufzeitzugriffsprüfen implemen tiert ist, dar, wenn ein Benutzer eine Handlung durch einen URL aufruft, wenn derselbe das CGI-Programm ovlaunch verwen det. Ein Benutzer kann eine Handlung durch ein Starter fenster 714, indem ein Menügegenstand angeklickt wird, der nicht gefiltert wurde, oder durch einen Web-Browser 300 aufrufen, indem ein URL-Argument zu dem ovlaunch-URL direkt geliefert wird. Beide Anfragen werden zu einem Web-Server 302 weitergeleitet 304, 816 und führen zu der Ausführung 338 des CGI-Programms ovlaunch. Nach dem Verifizieren, daß eine Sitzung existiert, kann ovlaunch verifizieren, ob die ange forderte Handlung durch eine der aktiven Benutzerrollen des Benutzers ermöglicht ist, indem das ovsessionmgr nach diesen Informationen abgefragt wird. Das ovsessionmgr, das Be nutzerrolleninformationen versteckt hat, die aus dem ovlaunchreg 702 bei der Sitzungsinitialisierung erhalten wurden 708, gibt das Resultat zu dem ovlaunch 308 zurück 802. Wenn der Benutzer berechtigt ist, die Handlung durchzu führen, gibt das ovlaunch eine HTML-Seite zu dem Web-Browser zurück 338, 304, was zu einer automatischen Anfrage 304 an den Web-Server 302 führt, um das CGI-Programm 810 auszu führen 812, das durch den aufgerufenen URL angezeigt wird.

Fig. 9 stellt die Benutzerrollenzugriffssteuerung in einem Web-Browser, die durch ein Laufzeitzugriffsprüfen implemen tiert ist, dar, wenn ein Benutzer eine Handlung durch einen URL ohne das CGI-Programm ovlaunch aufruft. Wenn ein Be nutzer eine Handlung durch direktes Eintippen in einen URL durch den Web-Browser 300 ohne das CGI-Programm ovlaunch aufruft, führt ein Web-Server 302 das CGI-Programm 810 aus 812, das durch den aufgerufenen URL angezeigt wird. Das CGI-Programm des aufgerufenen URL verwendet eine Netz- Sitzung-C-API, um mit dem ovsessionmgr 316 zu kommunizieren 906, um zu verifizieren, daß eine Sitzung existiert, und daß die angefragte Handlung durch die Benutzerrollen für den aktuellen Benutzer ermöglicht ist. (Wie im vorhergehenden erörtert, erhält 708 das ovsessionmgr Benutzerrolleninfor mationen von dem ovlaunchreg 702 bei der Sitzungsinitiali sierung und versteckt diese Informationen.) Wenn es eine Sitzung gibt, und der Benutzer für die Handlung berechtigt ist, fährt das CGI-Programm die Ausführung fort, und führt die Handlung durch, für die dasselbe entworfen wurde (d. h. führt einen URL aus).

Bei einem zweiten bevorzugten Ausführungsbeispiel der Er findung ist die Benutzerrollenzugriffssteuerung in einer Netzumgebung implementiert, um einen Benutzer eine Berechti gung zu erteilen oder zu verweigern, eine Handlung aufzu rufen, wobei eine Zugriffsregel einem Benutzer Zugriffs rechte zu einer Handlung erteilt. Eine Zugriffsregel ist eine Beziehung zwischen einem spezifischen Operationssatz und einer spezifischen Domäne. Ein Operationssatz oder kurz Op-Satz, ist ein Satz von Handlungen, die an Objekten vorge nommen werden können. Die meisten Operationen dienen für ei ne spezifische Klasse von Objekten, einige derselben sind jedoch allgemeine Operationen, die nicht objektspezifisch sind. Beispiele von Operationen umfassen das Neustarten ei nes Systems, das Hinzufügen eines ATM-Schalters, das Finden eines Leitwegs und das Hinzufügen eines Datensatzes. Ein Operationssatz ist typischerweise eine Gruppierung von logisch verwandten Handlungen, wie z. B. alle Handlungen, die notwendig sind, um einen Drucker zu verwalten. Eine Domäne ist ein Satz von Objekten und/oder anderen Domänen, die verwendet werden, um die Größe und Komplexität der Führungsumgebung durch Aufteilen derselben in interes sierende Bereiche und Verantwortlichkeitsbereiche zu redu zieren. Domänen definieren die Zielobjekte, die geführt wer den, und sind für den Zweck des Anwendens einer allgemeinen Zugriffssteuerungspolitik auf alle Objekte in der Domäne gruppiert. Domänen können für eine Vielfalt von Zwecken, wie z. B. für geographische Zwecke, Netztopologiezwecke, funk tionelle Zwecke und organisatorische Zwecke definiert sein. Eine Domäne kann hinsichtlich eines Satzes von Regeln (z. B. "alle Leitvorrichtungen" (Router) oder "alle PCs, die mit Windows-NT-4.0 laufen") oder als explizit definierte Mit glieder definiert sein. Typischerweise sind die Objekte, die geführt werden, in der Benutzerrollendefinition inbegriffen. Beispielsweise könnte eine Benutzerrolle der Netzverwalter für die östlichen U. S. sein, während eine weitere Benutzer rolle der Netzverwalter für die westlichen U. S. sein könn te. Daher ist ein Benutzer berechtigt, eine Operation an einem Objekt durchzuführen, wenn der Benutzer eine Benutzer rolle aufweist, die eine Zugriffsregel enthält, die es er möglicht, daß die angeforderte Operation an dem angeforder ten Objekt durchgeführt wird. Beispielsweise ist ein Be nutzer berechtigt, eine Operation A an einem Objekt X durch zuführen, wenn dem Benutzer eine Benutzerrolle bewilligt wurde, die eine Zugriffsregel enthält, die als eine Paarung zwischen dem Operationssatz P und der Domäne Q definiert ist, derart, daß A ein Mitglied von P und X ein Mitglied von Q ist. Dieses Ausführungsbeispiel ermöglicht es ferner, daß Zugriffsbeschränkungen oder zusätzliche Einschränkungen des Benutzerzugriffs definiert werden können und auf den Zu griffsrechten eines Benutzers definiert hinzugefügt werden können. Beispielsweise kann eine Zeitbeschränkung einen Be nutzer begrenzen, sich zwischen den Stunden 8:00 und 17:00 anzumelden, und eine Positionsbeschränkung kann einen Be nutzer begrenzen, einen Zugriff zu erlangen, wenn derselbe in einem bestimmten physisch sicheren System angemeldet ist. Die Benutzerrollenzugriffssteuerung bei diesem Ausführungs beispiel kann in Hewlett-Packard OpenView® Anwendungen im plementiert sein.

Wenn sich ein Benutzer bei einer OpenView-Anwendung anmel det, meldet sich ein Benutzer an, und nimmt eine oder mehre re Benutzerrollen bei diesem Ausführungsbeispiel ein. Der Benutzer besitzt einen Satz von bewilligten Benutzerrollen, die alle Benutzerrollen sind, für die dem Benutzer eine Erlaubnis gegeben wurde. Wenn sich der Benutzer anmeldet, beansprucht der Benutzer einen Teilsatz der verfügbaren be willigten Benutzerrollen, die als die beanspruchten zu griffsrechte oder aktiven Benutzerrollen bekannt sind. Diese aktiven Benutzerrollen bestimmen, welche Art der Benutzer schnittstelle der Benutzer hinsichtlich dessen sieht, welche Menüs angezeigt sind und welche Objekte sichtbar sind. Alle Operationen in den Operationssätzen für die aktiven Be nutzerrollen werden durch die GUI-Steuerungen verfügbar gemacht, wie z. B. durch Menüs und Knöpfe. Operationen, die nicht in den Operationssätzen für die aktiven Benutzerrollen erscheinen, erscheinen nicht in den GUI-Steuerungen. Wenn der Benutzer dynamisch eine neue Rolle zu der Liste der aktiven Benutzerrollen hinzufügt, erscheinen die GUI-Steue rungen für diese Operation in der Benutzerschnittstelle. Ähnlicherweise sind alle Objekte in jeder der Domänen, die in den Zugriffsregeln für die aktiven Benutzerrollen umfaßt sind, durch die Benutzerschnittstelle sichtbar. Objekte, die sich nicht in diesen Domänen befinden, sind nicht durch die Benutzerschnittstelle sichtbar. Die aktiven Benutzerrollen eines Benutzers bestimmen ferner, welche Laufzeitoperationen der Benutzer durchführen kann. Bei diesem Ausführungsbei spiel kann ein Benutzer ferner zwischen Rollen dynamisch wechseln, um ein Privileg hinzuzufügen oder zu entfernen, das nützlich ist, wenn ein Benutzer bestimmte Rollen ge legentlich (d. h. wenn ein Mitarbeiter krank ist) benötigt. Die Existenz einer Operation und eines Objekts in der Benut zerschnittstelle, bedeutet nicht, daß der Benutzer diese Operation an diesem Objekt durchführen kann, da die Opera tion und das Objekt zu unterschiedlichen Zugriffsrollen ge hören können. Wenn es beispielsweise eine Zugriffsregel gibt, die es dem Benutzer ermöglicht, eine Operation A an einem Objekt X durchzuführen, und eine Operation B an einem Objekt Y durchzuführen, bedeutet dies nicht, daß der Be nutzer eine Operation A an dem Objekt Y durchführen kann. Aus diesen und anderen Gründen, wie z. B. der Tatsache, daß ein Sicherheitsverwalter die Zugriffsrechte eines Betreibers ändern kann, umfaßt die Erfindung ferner das Laufzeitzu griffsprüfen. Zu dem Zeitpunkt, zu dem der Benutzer anfragt, eine Handlung A an dem Objekt X durchzuführen, wird eine Prüfung durchgeführt, um festzustellen, daß es eine Zu griffsregel (d. h. ein Op-Satz/Domänen-Paar) in einer der aktiven Benutzerrollen gibt, in der A ein Mitglied des Ope rationssatzes für die aktiven Benutzerrollen ist, und X ein Mitglied der Domäne für diese Zugriffsregel ist. Diese Hand lung ist möglich, wenn beide Bedingungen wahr sind.

Fig. 10 stellt ein Beispielsicherheitsmodell für ein zweites bevorzugtes Ausführungsbeispiel dar, das eine Benutzerregel 1000, einen Operationssatz 1002 und eine Domäne 1004 defi niert. Bei diesem Beispiel sind die Benutzer 1014 Joe Smith und Sue Edwards Mitglieder der Benutzerrolle NFS Verwalter 1006. Dieselben besitzen Zugriffsregeln 1024, 1026, 1028, 1030, um einen Satz von Operationen in einem oder mehreren Operationssätzen 1008 an einem Satz von Objekten in einer oder mehreren Objektdomänen 1010 durchzuführen. Die Op-Sätze sind dort definiert, wo der Op-Satz NFS_Verwalter 1016 die Operationen und/oder Operationssätze 1018 NFS-Server-Lesen, NFS-Server-Konfigurieren, Knoten-Lesen und Sichtbarkeit um faßt. Die Domänen sind ferner dort definiert, wo die Domäne Osten 1020 die Objekte und/oder Domänen 1022 doc_serv1, Kno ten-Osten, doc_serv1:/,, und doc_serv:/ProjDocs enthält. Wenn sich daher beispielsweise Joe Smith in der Benutzerrolle NFS_Verwalter anmeldet und versucht, eine NFS-Server-Lesen- Operation (die in dem NFS Verwalter-Op-Satz definiert ist) in der Domäne Osten durchzuführen, wird die Zugriffsregel, die {NFS_Verwalter, Osten} definiert, ihm einen Zugriff erteilen. Auf der anderen Seite wird ihm, wenn er versucht, dasselbe in der Domäne Süden durchzuführen, der Zugriff ver weigert, da es keine Zugriffsregel gibt, die {NFS Verwalter, Süden} definiert.

Fig. 11 stellt ferner eine Benutzerrollenzugriffssteuerung bei einem zweiten bevorzugten Ausführungsbeispiel dar, bei dem die Benutzer 1100, 1102, 1104 einer oder mehreren Be nutzerrollen 1114, 1116 zugewiesen sind 1106, 1108, 1110, 1112. Jede Benutzerrolle kann durch eine oder mehrere Zu griffsregeln 1118, 1120, 1122, 1124 oder Paarungen von Operationssätzen 1126, 1128 zu Domänen 1130, 1132 definiert sein. Beispielsweise besitzt die Benutzerrolle Betreiber Osten zwei Zugriffsregeln: {Router-Verwalter, Osten} und {Sicherheits-Verwalter, Osten}.

Die Benutzerrollenzugriffssteuerung ist ein leistungsvolles und vielseitiges Sicherheitsmodell, das es einem Benutzer ermöglicht, sich in einer oder mehreren Benutzerrollen an zumelden und/oder zwischen Rollen dynamisch zu wechseln. Bei den bevorzugten Ausführungsbeispielen der Erfindung ist die Benutzerrollenzugriffssteuerung in einer Netzumgebung imple mentiert, um zu filtern, was der Benutzer sieht, und/oder um ein Laufzeitzugriffsprüfen dafür zu implementieren, welche Handlung der Benutzer durchführt. Die Merkmale dieses Sicherheitsmodells lösen existierende Probleme, die bei ak tuellen Modellen angetroffen werden, wie z. B. die Domänen modellsicherheit, indem eine flexible Konfiguration und Im plementation vorgesehen wird.

Obwohl die Ausführungsbeispiele der Benutzerrollenzugriffs steuerung, die in der Beschreibung beschrieben sind, auf das Bestimmen von Handlungen gerichtet sind, die ein Benutzer durchführen kann, indem diese Handlungen in einer GUI ge filtert werden, ist es offensichtlich, daß eine Benutzer rollenzugriffssteuerung auf eine andere Art und Weise ausge führt sein kann. Die Benutzerrollenzugriffssteuerung kann ferner verwendet werden, um Handlungen zu bestimmen, die ein Benutzer durchführen kann, indem dieselbe jene Handlungen "im Hintergrund" filtert, bei denen es für einen Benutzer durchsichtig ist, worauf der Benutzer einen Zugriff besitzt oder nicht. Beispielsweise kann eine Benutzerrolle ferner Handlungen bestimmen, die ein Benutzer durchführen kann, indem die Vorrichtungen gefiltert werden, zu denen der Be nutzer einen Zugriff besitzt oder an denen der Benutzer Handlungen durchführen kann. Bei diesem Beispiel kann eine Benutzerrolle bestimmen, daß ein Benutzer einen Zugriff zu Datendateien besitzt, die in einer Vorrichtung 1 und einer Vorrichtung 2 jedoch beispielsweise nicht in einer Vorrich tung 3 liegen. Obwohl der Benutzer einen Zugriff auf Daten dateien in der Vorrichtung 1 und der Vorrichtung 2 besitzt, werden dieselben nicht in einer GUI, so daß der Benutzer dieselben sehen kann, angezeigt, sondern dieselben werden vielmehr durch eine oder mehrere aktive Benutzerrollen "im Hintergrund" bestimmt.

Claims

1. Vorrichtung zum Steuern eines Benutzerzugriffs auf Com puterbasierte Objekte, mit folgenden Merkmalen:

a) einem oder mehreren Computer-lesbaren Speicherme dien (232);
b) einem Programmcode, der in dem einen oder den mehreren Computer-lesbaren Speichermedien (232) liegt, zum Erzeugen von einer oder mehreren Be nutzerrollen (200, 202, 204),
- a) wobei jede der einen oder mehreren Benutzer rollen einen Satz von Zugriffsrechten (226, 228, 230) aufweist, der einem Satz von Be nutzern zugeordnet ist; und
- b) wobei jedes der Zugriffsrechte Handlungen (206, 208, 210, 212, 214, 216, 218, 220, 222), die durch einen Benutzer in dem Satz von Benutzern durchgeführt werden können, an einem Satz der Computer-basierten Objekte.

2. Vorrichtung gemäß Anspruch 1, bei der mindestens ein Benutzer in einem gegebenen Satz von Benutzern ein Com puter-basierter Server ist.

3. Vorrichtung gemäß Anspruch 1 oder 2, die ferner einen Programmcode aufweist, der in dem einen oder den mehre ren Computer-lesbaren Speichermedien (232) liegt, zum

a) Bestimmen, jedesmal, wenn ein gegebener Benutzer eine Computersitzung einleitet, welche der einen oder mehreren Benutzerrollen (200, 202, 204) aktiv sind und auf den gegebenen Benutzer Bezug nehmen; und
b) Filtern der Handlungen (206, 208, 210, 212, 214, 216, 218, 220, 222), die durch einen Benutzer in dem Satz von Benutzern an einem Satz der Compu terbasierten Objekte durchgeführt werden können, basierend auf der einen oder den mehreren Benut zerrollen, die aktiv sind und auf den gegebenen Benutzer Bezug nehmen, und wie es durch beliebige Zugriffsrechte (226, 228, 230) bestimmt ist, die dem gegebenen Benutzer in der einen oder den mehreren Benutzerrollen zugeordnet sind.

4. Vorrichtung gemäß Anspruch 3, bei der das Filtern der Handlungen (206, 208, 210, 212, 214, 216, 218, 220, 222), die durch einen Benutzer in dem Satz von Benut zern durchgeführt werden können, an einem Satz der Com puterbasierten Objekte, das Filtern von Elementen von einer oder mehreren graphischen Benutzerschnittstellen aufweist, die dem gegebenen Benutzer dargestellt wer den, um dem gegebenen Benutzer lediglich jene Elemente aktiv anzuzeigen, auf die der gegebene Benutzer zugrei fen darf.

5. Vorrichtung gemäß Anspruch 4, bei der das Filtern das Filtern von angezeigten Icons aufweist.

6. Vorrichtung gemäß Anspruch 4, bei der das Filtern das Filtern von angezeigten Menügegenständen aufweist.

7. Vorrichtung gemäß Anspruch 1, die ferner einen Pro grammcode aufweist, der in dem einen oder den mehreren Computer-lesbaren Speichermedien (232) liegt, zum

a) Bestimmen, jedesmal, wenn ein gegebener Benutzer eine Anwendung startet, welche der einen oder mehreren Benutzerrollen (200, 202, 204) aktiv sind und auf den gegebenen Benutzer Bezug nehmen; und
b) Filtern der Handlungen (206, 208, 210, 212, 214, 216, 218, 220, 222), die durch einen Benutzer in dem Satz von Benutzern an einem Satz der Compu terbasierten Objekte durchgeführt werden können, basierend auf der einen oder den mehreren Be nutzerrollen, die aktiv sind und auf den gegebenen Benutzer Bezug nehmen, und wie es durch beliebige Zugriffsrechte (226, 228, 230) definiert ist, die dem gegebenen Benutzer zugeordnet sind.

8. Vorrichtung gemäß Anspruch 7, bei der das Filtern der Handlungen (206, 208, 210, 212, 214, 216, 218, 220, 222), die durch einen Benutzer in dem Satz von Benut zern durchgeführt werden können, an einem Satz der Com puterbasierten Objekte, das Filtern von Elementen von einer oder mehreren graphischen Benutzerschnittstellen aufweist, die dem gegebenen Benutzer dargestellt wer den, um dem gegebenen Benutzer lediglich jene Elemente aktiv anzeigen, auf die der gegebene Benutzer zugreifen darf.

9. Vorrichtung gemäß Anspruch 8, bei der das Filtern das Filtern von angezeigten Icons aufweist.

10. Vorrichtung gemäß Anspruch 8, bei der das Filtern das Filtern von angezeigten Menügegenständen aufweist.

11. Vorrichtung gemäß Anspruch 1, die ferner einen Pro grammcode aufweist, der in dem einen oder den mehreren Computer-lesbaren Speichermedien (232) liegt, zum

a) Verifizieren, jedesmal, wenn ein gegebener Be nutzer versucht, eine Handlung (206, 208, 210, 212, 214, 216, 218, 220, 222) an einem gegebenen Computer-basierten Objekte durchzuführen, ob der gegebene Benutzer und das gegebene Computerba sierte Objekt in einer aktiven der einen oder mehreren Benutzerrollen (200, 202, 204) zugeordnet sind; und
b) Bewilligen lediglich des gegebenen Benutzerzu griffs auf das gegebene Computer-basierte Objekt, wenn der gegebene Benutzer und das gegebene Compu terbasierte Objekt in einer aktiven der einen oder mehreren Benutzerrollen zugeordnet sind.

12. Vorrichtung gemäß Anspruch 1, bei der gegebene der Handlungen (206, 208, 210, 212, 214, 216, 218, 220, 222) einen Zugriff zu Einheits-Ressourcen-Positions anzeigern (URLs; URL = Uniform Resource Locator) in einer Netz-basierten Umgebung aufweisen.

13. Vorrichtung gemäß Anspruch 12, die ferner einen Pro grammcode aufweist, der in dem einen oder den mehreren Computer-lesbaren Speichermedien (232) liegt, zum

a) Bestimmen, jedesmal, wenn ein gegebener Benutzer eine Computersitzung einleitet, welche der einen oder mehreren Benutzerrollen (200, 202, 204) aktiv sind und auf den gegebenen Benutzer Bezug nehmen; und
b) Filtern von Elementen, die auf einen oder mehrere URLs in einer oder mehreren graphischen Benutzer schnittstellen Bezug nehmen, die dem gegebenen Be nutzer dargestellt werden, um dem gegebenen Be nutzer lediglich jene Elemente, die auf URLs Bezug nehmen, anzuzeigen, auf die der gegebene Benutzer zugreifen darf, basierend auf der einen oder den mehreren Benutzerrollen (200, 202, 204), die aktiv sind und auf den gegebenen Benutzer Bezug nehmen, und wie es durch beliebige Zugriffsrechte (226, 228, 230) bestimmt ist, die dem gegebenen Benutzer zugeordnet sind.

14. Vorrichtung gemäß Anspruch 13, die ferner einen Pro grammcode aufweist, der in dem einen oder den mehreren Computer-lesbaren Speichermedien (232) liegt, zum

a) Verifizieren, jedesmal, wenn ein gegebener Be nutzer versucht, auf den gegebenen URL zuzugrei fen, ob der gegebene Benutzer und der gegebene URL in einer aktiven der einen oder mehreren Benutzer rollen (200, 202, 204) zugeordnet sind; und
b) Bewilligen lediglich des gegebenen Benutzerzu griffs zu dem gegebenen URL, wenn der gegebene Be nutzer und der gegebene URL in einer aktiven der einen oder mehreren Benutzerrollen (200, 202, 204) zugeordnet sind.

15. Vorrichtung gemäß Anspruch 12, die ferner einen Pro grammcode aufweist, der in dem einen oder den mehreren Computer-lesbaren Speichermedien (232) liegt, zum

a) Verifizieren, jedesmal, wenn ein gegebener Be nutzer versucht, auf einen gegebenen URL zuzugrei fen, ob der gegebene Benutzer und der gegebene URL in einer aktiven der einen oder mehreren Benutzer rollen (200, 202, 204) zugeordnet sind; und
b) Bewilligen lediglich des gegebenen Benutzerzu griffs auf den gegebenen URL, wenn der gegebene Benutzer und der gegebene URL in einer aktiven der einen oder mehreren Benutzerrollen (200, 202, 204) zugeordnet sind.

16. Vorrichtung gemäß Anspruch 12, die ferner folgende Merkmale aufweist:

a) ein Starterobjekt, das in dem einen oder mehreren Computer-lesbaren Speichermedien liegt, zum
- a) Darstellen einem Benutzer eines Anmeldebild schirms, der den Benutzer nach Benutzerinfor mationen auffordert; und
- b) Aufrufen eines Anmeldeobjekts;
b) wobei das Anmeldeobjekt in dem einen oder den mehreren Computer-lesbaren Speichermedien (232) liegt, zum
- a) Lesen der Benutzerinformationen;
- b) Verifizieren der Computersitzung, Aufrufen eines Sitzungsführungsobjekts und Weiterlei ten der Benutzerinformationen zu dem Sitzungsführungsobjekt, wenn der Benutzer be reits eine Computersitzung eingeleitet hat; und
- c) Einleiten einer Computersitzung durch Aufru fen des Sitzungsführungsobjekts und Weiter leiten der Benutzerinformationen zu dem Sitzungsführungsobjekt, wenn der Benutzer nicht bereits eine Computersitzung eingelei tet hat; und
c) wobei das Sitzungsführungsobjekt, in dem einen oder den mehreren Computer-lesbaren Speichermedien (232) liegt, zum
- a) Beglaubigen der Benutzerinformationen;
- b) Bestimmen, welche der einen oder mehreren Be nutzerrollen (200, 202, 204) auf den gegebe nen Benutzer Bezug nehmen, wenn die Benutzer informationen beglaubigt sind; und
- c) Verweigern des Benutzerzugriffs zu einer Com putersitzung, wenn die Benutzerinformationen nicht beglaubigt sind.

17. Vorrichtung gemäß Anspruch 1, bei der jedes der einen oder mehreren Zugriffsrechte (226, 228, 230) durch eine oder mehrere Zugriffsregeln bestimmt wird, wobei jede der einen oder mehreren Zugriffsregeln ein Operations satz/Objektdomänen-Paar aufweist, wobei

a) die Objektdomäne eines oder mehrere Objekte auf weist, auf die ein Benutzer, auf den in einer Be nutzerrolle (200, 202, 204) Bezug genommen wird, einen Zugriff besitzt; und
b) der Operationssatz eine oder mehrere Handlungen (206, 208, 210, 212, 214, 216, 218, 220, 222) auf weist, die ein Benutzer, auf den in einer Benut zerrolle Bezug genommen wird, durchführen kann.

18. Vorrichtung gemäß Anspruch 17, die ferner einen Pro grammcode aufweist, der in dem einen oder den mehreren Computer-lesbaren Speichermedien (232) liegt, zum Er zeugen der einen oder der mehreren Zugriffsregeln.

19. Vorrichtung gemäß Anspruch 17 oder 18, bei der das eine oder die mehreren Zugriffsrechte (226, 228, 230) durch eine oder mehrere Zugriffsbeschränkungen begrenzt sind.

20. Vorrichtung gemäß Anspruch 19, die ferner einen Pro grammcode aufweist, der in dem einen oder den mehreren Computer-lesbaren Speichermedien (232) liegt, zum Er zeugen der einen oder mehreren Zugriffsbeschränkungen.

21. Ein Verfahren zum Steuern eines Benutzerzugriffs auf Computer-basierte Objekte, mit folgenden Schritten:

a) Empfangen einer Anfrage von einem Benutzer, eine Handlung während einer Computersitzung durch zuführen;
b) Wiedergewinnen ansprechend auf die Anfrage von einer oder mehreren Benutzerrollen (200, 202, 204), von denen der Benutzer ein Mitglied für die Sitzung ist, wobei jede der einen oder mehreren Benutzerrollen eines oder mehrere Zugriffsrechte (226, 228, 230) bestimmt, die der Benutzer für die Sitzung besitzt, wobei das eine oder die mehreren Zugriffsrechte eine oder mehrere Handlungen (206, 208, 210, 212, 214, 216, 218, 220, 222) bestimmen, die der Benutzer während der Sitzung durchführen kann; und
c) Bestimmen, ob der Benutzer berechtigt ist, die angefragte Handlung durchzuführen, durch Be stimmen, ob die eine oder die mehreren Benutzer rollen, von denen der Benutzer ein Mitglied ist, ein Zugriffsrecht aufweisen, das die angefragte Handlung erlaubt.

22. Verfahren gemäß Anspruch 21, bei dem eines der einen oder mehreren Zugriffsrechte (226, 228, 230) bestimmt, ob ein Benutzer auf einen oder mehrere Einheits-Res sourcen-Positionsanzeiger (URLs) in einer Netzbasier ten Umgebung zugreifen kann.