DE60102934T2

DE60102934T2 - Verfahren und system für sitzungsbasierte berechtigung und zugangskontrolle für vernetzte anwendungsobjekte

Info

Publication number: DE60102934T2
Application number: DE60102934T
Authority: DE
Inventors: Sebastian Staamann; Tim Eckardt
Original assignee: XTRADYNE TECHNOLOGIES AG
Current assignee: Prismtech 10119 Berlin De GmbH
Priority date: 2000-08-04
Filing date: 2001-05-12
Publication date: 2005-03-10
Anticipated expiration: 2021-05-13
Also published as: WO2002013437A3; WO2002013437A2; US7441265B2; AU2001263929A1; EP1307988A2; US20030145094A1; DE60102934D1; ATE265112T1; EP1307988B1

Description

Diese Erfindung behandelt im allgemeinen eine Methode zur Steuerung der Sicherheit in einem Computernetzwerk.
Hintergrund der Erfindung
Insbesondere handelt es sich bei dieser Erfindung um ein Verfahren, den Zugriff auf Anwendungsobjekte zu kontrollieren, welche, um sie Anwendern und Anwendungsprozessen über ein oder mehrere Computernetzwerke zugänglich zu machen, eben auch einer Vielzahl, dem Eigentümer der Anwendungsobjekte unbekannten, sowie potentiell boshaften und betrügerische Absichten verfolgenden anderen Teilnehmern eben dieses oder dieser Computernetzwerke offenbart werden.
In vernetzten Computerumgebungen werden Anwendungsprogrammsysteme immer häufiger als Systeme, die aus einer Vielzahl über wohldefinierte Operationen ansprechbaren vernetzten Objekte bestehen, implementiert. Web-Anwendungen (Web Applications), Verteilte Objekte (Distributed Objects), Komponenten (Components) und Netzobjekte (Net Objects) sind häufig verwendete Ausdrücke für diesen Ansatz Programmsysteme zu erstellen. Typischerweise greifen die Anwender (menschliche Anwender als auch unter einer bestimmten Identität auftretende maschinenbasierte Einheiten) solcher verteilter Programmsysteme über ein Netzwerk auf dieses System zu. Die Benutzung eines Anwendungsprogramms das aus mehreren Objekten besteht bedeutet für den Anwender den Zugriff auf eine Vielzahl von Objekten während jeder Nutzung des Programmsystems. CORBA Objekte, über das Netzwerk erreichbare Java Objekte, über das Netzwerk erreichbare DCOM Komponenten und statische oder dynamisch erzeugte HTML oder WAP Seiten von Web Anwendungen sind Beispiele solcher Objekte. Die wohldefinierten Operationen sind entweder Operationen, die explizit für den Objekttyp in der Schnittstellendefinitionssprache (IDL) der zugehörigen Technologie (CORBA, Java, DCOM) definiert sind, oder es sind Operationen, die implizit definiert und implementiert sind als eine Kombination von generischen Protokollmethoden mit wohldefinierten Parametertypen (Web Anwendungen).
Jedes der jeweiligen Objekte hat eine spezifische Referenz welche benutzt wird, um auf es zuzugreifen. Vor der Benutzung der Anwendung hat der Anwender normalerweise noch nicht alle nötigen Referenzen. Er hat sich im Normalfall vor Nutzung der Anwendung eine einzige Referenz beschafft die ein Objekt referenziert, welches als Startpunkt zur Benutzung der Anwendung dient. Die benötigten Referenzen zum Zugriff auf andere Objekte erhält er während seiner Interaktion mit dem Anwendungsprogrammsystem. Die Referenz auf ein Objekt auf das zugegriffen werden soll wird normalerweise in der Ausgabe von anderen Anwendungsobjekten, auf die bereits vorher zugegriffen wurde, angeliefert und empfangen. Die Ausgabe wird vom Anwender in der Form von Webseiten oder Objektausgabeparametern empfangen.
Eine Referenz enthält die Information, welche für das Computersystem des Anwenders technisch notwendig ist, um eine Transportverbindung mit den erforderlichen Eigenschaften (z.B. eine TCP Verbindung) zu dem Computersystem des zugehörigen Objekts aufzubauen, als auch die Informationen die dem Computersystem des zugehörigen Objekts erlauben, dieses Objekt innerhalb dieses Computers zu adressieren. CORBA IORs, Java-RMI Referenzen, DCOM Referenzen und URIs sind Beispiele für Referenzen in den o.a. objektbasierten Technologien.
Die Objekte, auf die vom Anwender während der Benutzung des Programmsystems zugegriffen werden sollen, sind in vielen Fällen exklusiv für diesen Anwender bestimmt. Dies dient z.B. zur Sicherheitsseparation und dem individualisierten Verhalten oder der individualisiert erzeugten Ausgabe der beteiligten Objekte. Diese Objekte können spezifisch für den jeweiligen Anwender und die jeweilige Benutzung und Zugriff (oft Sitzung genannt) dynamisch erzeugt werden. Die Erzeugungszeit kann variieren, z.B. kann das Objekt erzeugt werden bevor die Referenz an den beabsichtigten Anwender ausgehändigt wird (z.B. nach dem Fabrik-Muster [feststehender auch im Deutschen üblicher engl. Begriff „Factory Pattern"] in CORBA-Anwendungen, Servlet-Instanzen für dynamisch generiertes HTML). Die Referenzen zu solchen anwender- und/oder sitzungsspezifischen Objekten werden von dem Programmsystem willentlich nur an den zugehörigen Anwender übergeben. Aus Sicht des Programmsystems und seines Anwendungsprogrammierers ist die Referenz semantisch nicht nur ein Zugang zu dem Objekt für den Anwender sondern auch eine implizite Autorisierung für den Zugriff.
Die Funktionalität aktueller verteilter objektorientierter Technologie ermöglicht kein effizientes Zugriffskontrollsystem welches die Erfordernisse der o.a. impliziten Autorisierung erfüllt. Insbesondere wird nicht überprüft, ob die Referenz zu einem bestimmten Objekt, die von einem bestimmten Anwender zum Zugriff auf das Objekt verwendet wird, vom Eigentümer des angesprochenen Objekts zum zugreifenden Anwender übermittelt wurde oder nicht. Sie erzwingen also nicht die für eine sichere Verwirklichung der o.a. impliziten Autorisierung benötigte Zugriffskontrolle. Betrügerische Anwender können in solchen Systemen abgefangene, verfälschte oder gefälschte Referenzen verwenden, um unberechtigt auf Objekte zuzugreifen. Abfangen und verfälschen von Referenzen ist oft wegen den bei der Kommunikation verwendeten unsicheren Datenübertragungswegen (z.B. dem Internet) möglich. Fälschen von Referenzen ist immer möglich, da sie Standardformate haben und die enthaltenen Werte leicht erraten werden können.
Zur Zeit bekannte Zugriffskontrollverfahren gestatten keine gesicherte implizite Autorisierung. Grund hierfür ist, daß die gesicherte implizite Autorisierung hauptsächlich angebracht ist für Systeme mit vielen kurzlebigen Objekten, wohingegen sich die Forschung im Gebiet der Zugriffskontrollkonzepte und Technologien überwiegend auf die weniger dynamischen Bereiche von langlebigen Dokumenten und Computerressourcen konzentriert hat.
Aus EP 0 816 989 A2 ist ein Fähigkeits- (feststehender auch im Deutschen üblicher engl. Begriff „Capability") basiertes System für verteilte objektorientierte Programme bekannt. Dieses System besteht aus einer Vielzahl von Objekten, von denen jedes einen privaten und einen öffentlichen Schlüssel enthält. Der öffentliche Schlüssel wird als Referenz auf sein zugehöriges Objekt verwendet. Der Zugriff auf ein bestimmtes Objekt ist für andere Objekte nur möglich, wenn sie dessen öffentlichen Schlüssel kennen. Dieser wird den anderen Objekten nach den Capability-Sicherheitsregeln (Fähigkeitssicherheitsregeln) bekannt gegeben. Die in diesem Dokument beschriebene Technologie offenbart nicht die Funktionalität eines effizienten Zugriffskontrollsystems welches die Erfordernisse der impliziten Autorisierung erfüllt; insbesondere wird nicht geprüft, ob die Erlaubnis zur Verwendung einer Referenz zu einem bestimmten Objekt von einem bestimmten Anwender zum Zugriff auf dieses Objekt zwischen dem Eigentümer dieses Objekts und dem Anwender ausgehandelt wurde.
Jedoch erfordern die modernen netzwerkbasierten Anwendungsprogrammsysteme, welche aus einer Vielzahl von verteilten Objekten bestehen (die Standardtechnologie des Internets werden), ein Autorisierungs- und Zugriffskontrollverfahren, welches die gesicherte implizite Autorisierung von über das Netzwerk verbundenen Anwendern mittels Exportieren von Objektreferenzen als Teil von, und kontrolliert durch, Anwendungslogik ermöglicht.
Aus diesem Grund ist es Aufgabe dieser Erfindung, Verfahren und Systeme für eine gesicherte implizite Autorisierung bereitzustellen, welche eine Zugriffskontrolle erzwingen und den unrechtmäßigen Zugriff dadurch technisch unmöglich machen.
Diese Aufgabe wird mit den Methoden aus Anspruch 1 und dem System aus Anspruch 6 gelöst. In den abhängigen Ansprüchen werden vorteilhafte Ausführungsformen dieser Methoden und Systeme beschrieben.
Für einen Fachmann ist es im Kontext der vorliegenden Erfindung offensichtlich, daß aus einem oder mehreren Initiatorhosts bestehende Initiatordomänen existieren können, von denen jeder Initiatorhost Dienste von einem oder mehreren Zielhosts aus einer Zieldomäne anfordern kann, wobei dies vorzugsweise unter Verwendung der in dieser Erfindung beschrieben Verfahren und Systeme aus vernetzten Anwendungsobjekten geschieht.
Die Ausführungsformen der Verfahren nach der vorliegenden Erfindung sind auf einem Computersystem implementierbar. In einer weiteren Ausführungsform kann die hier beschriebene Erfindung als ein Computerprogrammprodukt zur Benutzung auf einem Computersystem implementiert werden. Dem Fachmann erschließt sich unmittelbar, daß Programme, welche die hier vorliegende Erfindung implementieren, einem Computer in vielen verschiedenen Erscheinungsformen bereitgestellt werden können, einschließlich aber nicht beschränkt auf:

– als auf einem nicht-beschreibbaren Speichermedium gespeicherte Informationen, z.B. von einem Computer E/A-Gerät lesbare Speicher wie ROMs oder CD-ROMs
– als auf einem beschreibbaren Speichermedium gespeicherte Informationen, z.B. Floppydisks oder Festplatten
– über einen Kommunikationskanal übertragende Informationen wie z.B einem Netzwerk oder über ein Modem in einem Telefonnetz.

Es ist klar, daß solche Medien, wenn sie zur Übermittlung von Anweisungen verwendet werden, welche die Methoden der hier beschrieben Erfindung implementieren, nichts anderes sind, als alternative Ausführungsformen eben dieser Erfindung.
Deshalb ist ein auf einem computerlesbaren Speichermedium gespeichertes Computerprogrammprodukt bestehend aus computerlesbaren Programmcodemitteln für ein Autorisierungs- und Zugriffskontrollverfahren auf Eingangssitzungsbasis zur Kontrolle des Zugriffs von einem Initiatorhost auf einen Zielhost, mit den folgenden Schritten:

(i) Empfangen einer ursprünglich von dem Initiatorhost kommenden Zugriffsanforderung, vorzugsweise einer Anforderungsnachricht, die ein Objekt auf dem Zielhost, auf das zugegriffen werden soll, referenziert,
(ii) Zuweisen der Zugriffsanforderung zu einer Eingangssitzung und Auswählen eines zu dieser Eingangssitzung gehörenden Sitzungskontextes,
(iii) Prüfen, ob der Zugriff auf das referenzierte Objekt in dem gewählten Sitzungskontext autorisiert ist oder nicht, und
(iv) Verweigern des Zugriffs auf das referenzierte Objekt wenn der Zugriff auf das Objekt auf dem Zielhost in dem gewählten Sitzungskontext nicht autorisiert ist,
(v) Gewähren des Zugriffs auf das referenzierte Objekt wenn der Zugriff auf das Objekt auf dem Zielhost in dem gewählten Sitzungskontext erlaubt ist,

Offenbarung (Zusammenfassung) der Erfindung
Um eine Vereinfachung der Beschreibung zu erreichen, werden im folgendem die Verfahren und Systeme auf Basis von CORBA als Beispieltechnologie für vernetzte Objekte beschrieben, obwohl die Verfahren und Prinzipien auch allgemein für Anwendungsprogrammsysteme, welche auf vernetzten Objekte basieren, gelten. Der Fachmann wird erkennen, daß die Prinzipien und Methoden auch auf Systeme vernetzter Objekte im Allgemeinen anwendbar sind, z.B. auf Java-RMI, DCOM und Web Anwendungen die statisch und dynamisch erzeugte HTML Seiten verwenden.
Wie bereits erwähnt, ist es das Ziel der hier vorliegenden Erfindung eine sichere Methode zur Realisierung der impliziten Autorisierung für Anwendungsprogramme, die aus individuell über das Netzwerk, wie z.B. das Internet, von Anwendern und Programmsystemen adressierbaren Objekten bestehen, zu beschreiben.
In der hier vorliegenden Erfindung wird die implizite Autorisierung in einer praktikablen und durchsetzbaren Art und Weise unter der Verwendung des neuartigen Verfahrens der Autorisierung auf Sitzungsbasis entwickelt. Dies heißt, der Vorgang der Aushändigung einer Referenz zu einem vernetzten Objekt durch den Eigentümer dieses Objekts zu einem Anwender mit einer bestimmten und überprüfbaren Identität (oder einer Einheit die unter einer solchen Identität agiert) beinhaltet die explizite Semantik, daß dieser Anwender innerhalb der zugehörigen Sitzung berechtigt ist auf das Objekt zuzugreifen, wobei die Sitzung eine temporäre Beziehung zwischen dem System des Anwenders und dem System des Objekteigentümers ist und bei der die Identität der beiden Parteien zur Zeit des Verbindungsaufbaus sichergestellt wurde und bei der die Echtheit der Sitzungspartner als auch der ausgetauschten Nachrichten durch geeignete technische Maßnahmen, wie z.B. der Anwendung von kryptographischen Methoden, deren Auswahl sich nach der Sicherheit richtet welche die Sicherheitsrichtlinen des Systems des Objekteigentümers erfordern, garantiert wird. Der Bestandteil der Zugriffskontrolle dieses Verfahrens erzwingt, daß auf ein Objekt außerhalb einer Sitzung auf keinerlei Art und Weise zugegriffen werden kann.
Ein Grundprinzip dieser Erfindung ist, daß die Autorisierung des Anwenders zum Zugriff auf das Objekt beschränkt ist auf Interaktionen innerhalb der Sitzung, innerhalb der er vom System des Objekteigentümers eine Referenz auf dieses Objekt erhalten hat. Im Normalfall, also im nicht näher ausgeführten Fall, wird die Autorisierung mit dem Erhalt der Referenz gültig und verfällt mit dem Ende der Sitzung.
Ein ergänzendes allgemeines Ziel dieser Erfindung ist es ein Verfahren zur Verfügung zu stellen, welches jede einzelne automatische sitzungsbasierte Autorisierung durch die erzwungene Verwendung weiterer und restriktiverer Sicherheitsrichtlinienregeln verfeinert. Dies verhindert die unerwünschte Autorisierung durch Programmcode der geschützten vernetzten Objekte, also z.B. im Fall von Standardsoftware die fehlerhafte Autorisierung z.B. durch Programmierfehler in dem Anwendungsprogrammcode.
Ein weiteres spezielleres Ziel dieser Erfindung ist es ein Verfahren zur Verfügung zu stellen, welches allgemein eine unzulässige Autorisierung verhindert und damit den unerwünschten Zugriff mittels des beschriebenen Systems zu bestimmten vernetzten Objekten, welche in den Sicherheitsrichtlinen des Systems des Objekteigentümers angegeben sind.
Ein weiteres Ziel dieser Erfindung ist es ein Verfahren zur Verfügung zu stellen, welches allgemein eine unzulässige Autorisierung von und damit den Zugriff durch bestimmte Anwender, welche in den Sicherheitsrichtlinien des Systems des Objekteigentümers angegeben sind, verhindert.
Ein weiteres Ziel dieser Erfindung ist es ein Verfahren zur Verfügung zu stellen, welches allgemeinen eine Autorisierung von und damit den Zugriff auf bestimmte vernetzte Objekte durch bestimmte Anwender, welche in den Sicherheitsrichtlinien des Systems des Objekteigentümers angegeben sind, verhindert.
Ein anderes Ziel dieser Erfindung ist es ein Verfahren zur Verfügung zu stellen zur individuellen Autorisierung je Objekt durch Beschränkung der Autorisierung des individuellen Anwenders auf eine Teilmenge der Objektoperationen, welche individuell ist für diesen Anwender, die Anwendergruppe welcher er angehört oder der Sicherheitsrollen, welche ihm in den Sicherheitsrichtlinien des Systems des Objekteigentümers zugewiesen wurden.
Noch ein anderes Ziel dieser Erfindung ist es ein Verfahren zur Verfügung zu stellen die Autorisierung derart einzuschränken, daß eine maximale Anzahl von Zugriffen pro autorisierter Operation auf das Objekt vorgegeben ist.
Ein weiteres Ziel dieser Erfindung ist es ein Verfahren zur Verfügung zu stellen, welches die Autorisierung auf einen Gültigkeitszeitraum beschränkt. Dies erlaubt, alternativ zum Sitzungseinschränkungsprinzip, eine Autorisierung mit einem festen Gültigkeitszeitraum.
Ein weiteres Ziel dieser Erfindung ist es Verfahren zur Autorisierung von statischen Objekten als auch dynamisch erzeugten Objekten zur Verfügung zu stellen, einschließlich einer Autorisierung mit den o.a. Einschränkungen.
Ein weiteres Ziel dieser Erfindung ist es Verfahren zur Verfügung zu stellen, welche es erlauben, die Autorisierung, einschließlich der in der o.a. Liste von Detaillierungen, zu beschreiben, in Abhängigkeit von sowohl einzelnen Instanzen von vernetzten Objekten, als auch des Objekttyps (bzw. der von diesem Objekt exportierten Schnittstelle). Letztere Fähigkeit wird insbesondere für die Sicherheitsrichtlinenregeln von dynamisch erzeugten Objekten bereitgestellt.
Ein anderes Ziel dieser Erfindung ist es Verfahren zur Verfügung zu stellen, die eine Abbildung einer oder mehrerer externer Identitäten, wie z.B „Kennzeichnende Namen' (feststehender auch im Deutschen üblicher engt. Begriff „Distinguished Names", abgekürzt DN) in den Zertifikaten von public-key Kryptosystemen, zu einer internen Identität erlauben, welche dann intern zur Autorisierung herangezogen wird. Dies erlaubt die Integration mit einer Vielzahl unterschiedlicher Anwendernamens-Schemata und -Systeme.
Ein anderes Ziel dieser Erfindung ist es sicherzustellen, daß die Zugriffskontrolle immer unter der Berücksichtigung der zuvor stattgefundenen Autorisierung durchgeführt wird. Alle Zugriffsversuche die zuvor nicht autorisiert wurden werden abgewiesen. Alle Einschränkungen der Autorisierung können nicht umgangen werden.
Eine vorteilhafte Ausführung eines, die Verfahren dieser Erfindung implementierenden, Systems ist dadurch gekennzeichnet, daß es als Interceptor (feststehender auch im Deutschen üblicher engt. Begriff) auf Anwendungsebene implementiert ist, vorzugsweise als ein auf einem Computersystem installiertes Softwaremodul und eine Anwendung, vorzugsweise ebenfalls ein Softwaremodul, welches die referenzierten Zielobjekte umfaßt.
In einer vorteilhaften Ausführung wird das System, welches das Verfahren dieser Erfindung implementiert, als ein Interceptor auf Anwendungsebene direkt auf der Server-Maschine eingebettet, um dort individuelle Anwendungen zu schützen, wie z.B. durch die Ausführung der impliziten Autorisierung und der Zugriffskontrolle sobald ein Zugriffsversuch auf jedwede objektbasierte Ressource stattfindet.
Das System, welches die Verfahren dieser Erfindung implementiert, kann als Gateway auf Anwendungsebene ausgeführt sein, vorzugsweise entweder als ein an ein einziges Netzwerk angeschlossener Host Computer oder als ein fest an zwei Netzwerke angeschlossener Host Computer, bei dem die Anwender im ersten Netzwerk und die vom System zu schützenden vernetzten Objekte im zweiten Netzwerk liegen. Diese beiden Netzwerke sind (zumindest logisch) getrennt und das System nach der hier vorliegenden Erfindung ist vorzugsweise das einzige Gateway zwischen diesen Netzwerken. Das System sollte unter der Kontrolle des Eigentümers der zu schützenden Objekte stehen.
Ein weiteres Ziel dieser Erfindung ist es, die Verfahren zum Bootstrapping des Autorisierungs- und Zugriffskontrollsystems bereitzustellen, indem es die Mittel zum schaffen der anfänglichen Kontaktpunkte für das Anwendungsprogrammsystem zur Verfügung stellt.
In einer bevorzugten Ausführungsform liefert das System die Mittel den gesamten, das System durchlaufenden, Netzwerkverkehr vollständig zu kontrollieren und schafft somit nicht nur eine Lösung zur Autorisierung und Zugriffskontrolle für die verwendete Technologie der vernetzten Objekte, sondern stellt auch eine Firewall Lösung für die zugrunde liegende Technologie der vernetzten Objekte, wie CORBA, DCOM oder Java-RMI, für das zweite Netzwerk bereit, wobei die gleiche Sicherheit erreicht wird, wie mit traditionellen auf Anwendungsebene arbeitenden Gateway-Firewalls.
In einer weiteren bevorzugten Ausführungsform der hier vorliegenden Erfindung können das Nachrichtenursprungsidentifikations/Authentifizierungs-Subsystem, das Zugriffskontrollentscheidungs- & Erzwingungs-Subsystem, das Subsystem für implizite Autorisierung und das Sitzungskontextverwaltungs-Subsystem eng mit der Implementation eines Proxy-Servers oder einer CORBA IIOP Brücke integriert sein. In einer solchen Implementation kann jede Zustandsinformation (z.B. durch den Proxy-Server erzeugte stellvertretende Proxy Objektreferenzen oder IORs), welche der Funktionsteil Proxy-Server während der Bearbeitung von entgegengenommenen Nachrichtendatenelementen im Kontext einer bestimmten Eingangssitzung W bei der Ausführung seiner Aufgabe erzeugt, als Teil des Sitzungskontextes (Sitzungskontextdatenelement) SC-W, welcher assoziiert ist mit der Eingangssitzung W, gehalten werden. Falls bei der Beendigung der Eingangssitzung W der Sitzungskontext SC-W gelöscht wird, so kann auch diese Zustandsinformation gelöscht werden.
Eine weitere Anwendung dieser Erfindung benutzt das Nachrichtenursprungsidentifikations/Autorisierungs-Subsystem und das Sitzungskontextverwaltungs-Subsystem als ein Mittel zur Lebensdauerverwaltung der Zustandsinformation (z.B. durch den Proxy-Server erzeugte stellvertretende Proxy Objektreferenzen oder IORs) die sich typischerweise in Proxy-Servern oder CORBA IIOP Brücken ansammeln. Bei der Verwendung des oben beschriebenen Mechanismus wird jede zusätzliche Zustandsinformation, die der Proxy-Server während der Bearbeitung einer gegebenen Nachricht generiert, mit genau dem Sitzungskontext SCW assoziiert, welcher vom Nachrichtenursprungsidentifikations/ Autorisierungs-Subsystem im Zusammenarbeit mit dem Sitzungskontextverwaltungs-Subsystem dieser Nachricht zugewiesen wurde. Diese Zustandsinformationen und die Ressourcen die benötigt werden, um diese Zustandsinformationen zu speichern, werden genau dann gelöscht, wenn das Sitzungskontextverwaltungs-Subsystem sich entscheidet den Sitzungskontext SC-W zu löschen.
Die hier vorgestellte Erfindung beschreibt ein umfassendes Verfahren, System und eine umfassende Technologie zur impliziten Autorisierung und Zugriffskontrolle. Implizite Autorisierung bedeutet, daß der vorgesehene Empfänger einer Objektreferenz zum Zugriff auf das von der Objektreferenz referenzierte Objekt berechtigt ist. Nur Anwender, die wirklich eine Referenz auf das Objekt von dem Eigentümer des Objekts erhalten haben, sind berechtigt auf das Objekt zuzugreifen. Jeder Versuch von Anderen auf das Objekt zuzugreifen, würde von einem vom oder für den Objektbesitzer eingesetzten Zugriffskontrollsystem verhindert werden. Dieses Zugriffskontrollsystem würde in einer Art und Weise in dem Computersystem, in dem das Objekt vorhanden ist, integriert sein, so daß Zugriffsversuche nicht das Zugriffskontrollsystem umgehen können.
Die mit der vorliegenden Erfindung vorgeschlagene Technik zur impliziten Autorisierung erlaubt eine kostengünstige Realisierung und den kostengünstigen Betrieb von sicheren vernetzten Anwendungen. Sie ist ein Baustein für Internetanwendungen, insbesondere von „Business-to-Business" (B2B) Programmsystemen. Ein Hauptvorteil ist die drastische Reduzierung der Komplexität der notwendigen Autorisierungs- und Zugriffskontrollverwaltungsaufgaben für die Programmsysteme. Implizite Autorisierung ermöglicht die Verwendung von externen Zugriffskontrollsystemen für bereits vorhandene Anwendungsprogrammsysteme in Form von extern definierter und konfigurierter, vollständiger und detailliert formalisierter Zugriffsrechte, ohne die Zugriffskontrolle in den vorhandenen Anwendungsprozessen zu implementieren und somit ohne die Notwendigkeit des Verständnisses und der Remodellierung der Anwendungslogik.
Benötigt wird die hier vorliegende Erfindung in Anwendungsgebieten wie:

– Bereitstellung einer Zugriffskontrolle für dynamisch erzeugte Ziele (z.B. Servlet-Sitzungen oder EJB [Enterprise Java Beans] Sitzungen, die einen Einkaufskorb zur Verfügung stellen) um den Zugriff eines Anwenders auf die Sitzung eines Anderen zu verhindern;
– Bereitstellung einer Zugriffskontrolle für Zugriffsanforderungen von anonymen Initiatoren;
– Bereitstellung von zweckmäßigen Verfahren zur Durchführung und Erzwingung der Zugriffskontrolle zu den dynamischen und statischen Webseiten eines HTTP Servers bei zwischengeschalteten Gateway-Maschinen.

Beispiele von verschiedenen Ausführungsformen dieser Erfindung sind in den Abbildungen veranschaulicht.
1a – 1c Blockdiagramme, die auf einer konzeptuellen Ebene den Ablauf der Sitzungsbasierten impliziten Autorisierung anhand von drei Beispielen aufzeigen.
2 Beispiel einer Netzwerktopologie als Blockdiagramm.
3 Blockdiagramm eines Sicherheitssystems, welches die hier beschriebene Erfindung an verschiedenen Punkten der Beispielnetzwerktopologie aus 2 anwendet.
4a Ein Blockdiagramm, welches eine Ausführungsform der vorliegenden Erfindung als Gateway auf Anwendungsebene auf einer Gateway-Maschine zeigt.
4b Ausführungsform der hier vorliegenden Erfindung als Interceptor auf Anwendungsebene auf einem Server als Blockdiagramm.
5a und 5b Flussdiagramme, welche die Verarbeitung von TCP Segmenten) oder Datagramm(en) innerhalb des Nachrichtenursprungsidentifikations/ Autorisierungs-Subsystems zeigen.
6a und 6b Flussdiagramme, welche die Verarbeitung von Datenelementen innerhalb des Zugriffskontrollentscheidungs- & Erzwingungs-Subsystems zeigen.
7a und 7b Flussdiagramme, welche die Verarbeitung von Datenelementen innerhalb des Subsystems für implizite Autorisierung zeigen.
8 Ein Blockdiagramm, das die allgemeine Struktur eines Sitzungskontextdatenelements (Sitzungskontext) zeigt.
9 Ein Flussdiagramm, das den Ablauf innerhalb des Sitzungskontextverwaltungs-Subsystems während der Verarbeitung einer „SELEKTIERE-KONTEXT" Anforderung des Nachrichtenursprungsidentifikations/Authentifizierungs-Subsystems zeigt.
10 Ein Flussdiagramm, das den Ablauf innerhalb des Sitzungskontextverwaltungs-Subsystems während der Verarbeitung einer „ÜBERPRÜFE-KONTEXT" Anforderung vom Zugriffskontrollentscheidungs- & Erzwingungs-Subsystems zeigt.
11 Ein Flussdiagramm, das den Ablauf innerhalb des Sitzungskontextverwaltungs-Subsystems während der Ausführung einer erweiterten Suche bei der Verarbeitung einer „ÜBERPRÜFE-KONTEXT" Anforderung vom Zugriffskontrollentscheidungs- & Erzwingungs-Subsystems zeigt.
12 Ein Flussdiagramm, das die erweiterte Verarbeitung von Funktionsblock SCM-37 aus 11 zeigt, welche zur Unterstützung der erweiterten Suche erforderlich ist.
13 Ein Flussdiagramm, das den Ablauf innerhalb des Sitzungskontextverwaltungs-Subsystems während der Verarbeitung einer „MODIFIZIERE-KONTEXT" Anforderung vom Subsystem für implizite Autorisierung zeigt.
Im folgenden Abschnitt wird die beste Ausführungsform und die gewerbliche Anwendbarkeit der hier vorliegenden Erfindung beschrieben.
Verteilte Systeme auf welche diese Erfindung anwendbar ist
Die vorliegende Erfindung, eine Methode und ein System zur impliziten Autorisierungs- und Zugriffskontrolle, ist allgemein anwendbar auf verteilte Verarbeitungssysteme bestehend aus mehreren, auf mehrere Hosts verteilte, Anwendungsprozesse, welche unter Verwendung eines Anforderungs-Antwort Protokolltyps, wie „Remote Procedure Calls" (RPC), „Remote Object Invocation" (ROI) oder eines beliebigen anderen auf Anwendungsebene ausgeführten Protokolls zum Zugriff auf die entfernten Anwendungsressourcen (z.B. statisch oder dynamisch erzeugter Inhalt), interagieren, wobei der vom Protokoll angeforderte Dienst oder das vom Protokoll adressierte Ziel objektbasiert ist, d.h. das mehrere Dienste oder Ziele auf demselben Host oder auf verschiedenen Hosts unterscheidbar sind und einzeln mittels Objektreferenzen oder URIs adressierbar sind.
Im weiteren werden diese Arten von Systemen einfach als verteilte Systeme bezeichnet. Die Objekte oder Ressourcen, auf welche mittels der auf Anwendungsebene ausgeführten Protokolle zugegriffen wird, können CORBA Objekte, Java Objekte, DCOM Objekte oder jedweder statisch oder dynamisch erzeugter HTML, XML oder WML Inhalt sein. Beispiele von RPC Protokollen, ROI Protokollen oder Protokollen zur Übertragung von Anwendungsressourcen die verteilte Systeme verwenden, auf welche die hier beschriebene Erfindung anwendbar sind, sind:

– das von der Object Management Group (OMG) definierte CORBA Internet Inter-ORB Protokoll (IIOP)
– Microsofts „Distributed Component Object Model" Protokoll (DCOM)
– Javas natives „Remote Object Invocation" Protokoll (ROI), welches von der Java Remote Method Invocation (RMI) verwendet wird und gelegentlich auch als Java Remote Method Protokoll (JRMP) bezeichnet wird
– das von Java RMI, als Alternative zum o.a. nativen ROI Protokoll, verwendete CORBA Internet Inter-ORB Protokoll (IIOP). Diese Alternative wird gelegentlich auch als Java IDL oder als Java RMI über IIOP bezeichnet.
– das zur Übertragung von HTML- und/oder anderem MIME-codierten Inhalt verwendete Hypertext Transfer Protokoll (HTTP).
– ein beliebiges Extensible Markup Language (XML)-basiertes RPC oder ROI Protokoll bei dem HTTP als Basis zur Übertragung von, in Standard HTTP Nachrichten (z.B. HTTP POST Anforderungen und Standard HTTP Antworten auf erfolgreiche POST Anforderungen) eingebetteten, XML-basierten Codierungen von RPCs, ROIs oder Antwortnachrichten, verwendet wird. Simple Object Access Protokoll (SOAP) ist ein Beispiel eines solchen Protokolls.
– das Wireless Application Protokoll (WAP) welches auf Anwendungsebene Interaktionen und Informationsaustausch, unter Benutzung einer standardisierten Inhaltscodierung, z.B. Wireless Markup Language (WML), binäres WAP XML Format, textbasierte Wireless Markup Language Skripts (WMLScript) oder Bytecode-codiertes kompiliertes WMLScript, mittels des Wireless Session Protokoll (WSP) und anderer geeigneter Protokolle tieferer Kommunikationschichten, erlaubt.
– beliebige Kombinationen der o.a. Protokolle sowie die darauf aufbauenden zukünftigen Versionen dieser Protokolle.

Dem Fachmann wird es möglich sein, das Design der hier vorliegenden Erfindung auf jedwedes andere, ein RPC oder ein ROI Protokoll verwendendes, verteilte System zu übertragen, das wie folgt charakterisiert ist:
In solchen verteilten Systemen sendet üblicherweise ein Anwendungsprozess in einer Klientenrolle (im folgendem als „Client" bezeichnet) eine Anforderungstyp-Nachricht (im folgendem als „Anforderungsnachricht" bezeichnet) zum einem anderen Anwendungsprozess in einer Serverrolle (im folgendem als „Server" bezeichnet), um dort entweder eine Methode bzw. einen RPC auf ein, auf diesem Server beherbergtes Zielobjekt auszuführen, oder um eine Abfrage oder Veränderung einer Zielressource, wie eine Inhaltsressource auf einem HTTP oder WAP Ursprungsserver, zu bewirken. Zum Zugriff auf das Zielobjekt oder die Zielressource benutzt der Client eine Zielobjekt- oder Zielressource- spezifische(n) Referenz bzw. Verweis, welche z.B. eine CORBA Interoperable Object Reference (IOR), eine DCOM Objektreferenz, eine Java RMI Objektreferenz oder ein Uniform Resource Identifier (URI) sein kann, wobei letzterer zur Referenz auf Objekte oder Ressourcen in nahezu allen der o.a. Anforderungs-/Antwort-basierten Protokollen oder ROI-Protokollen verwendet werden kann. Eine solche Objektreferenz oder URI (möglicherweise in Zusammenhang mit anderen Adressinformationen) ermöglicht dem Client die Server-Maschine zu erreichen und, indem er die vollständige oder einen Teil der Objektreferenz oder URI in dem Kopf- oder dem Parameter-Bereich der Nachricht ablegt, das spezifische Objekt bzw. die spezifische Ressource auf der Server-Maschine, welche das Ziel der Anforderungsnachricht sein soll, anzugeben. Nach der Verarbeitung der empfangenen Anforderungsnachricht kann der Server eine Antworttyp-Nachricht (im folgendem als „Antwortnachricht" bezeichnet) an den Client senden, welche die Ausgangsparameter, die Rückgabewerte, die Fehlerindikatoren oder den von der URI bezeichneten Inhalt, enthält.
Clients erhalten typischerweise im Verlauf der Interaktionen zwischen Clients und Servern dieser verteilten Systeme, neue, auf weitere Objekte oder Ressourcen verweisende, Objektreferenzen oder URIs. Diese, auf weitere Objekte oder Ressourcen verweisenden, Objektreferenzen und URIs können als Teil des Nachrichtenkopfes, als Teil des Nachrichtenkörpers, als Parameter, als Rückgabewert sowie als Teil einer Fehlerindikation, unter der Verwendung eines der o.a. Protokolle, vom Server an den Client gesendet werden.
Implizite Autorisierung auf Sitzungsbasis
Die hier vorliegende Erfindung offenbart ein System und ein Verfahren (engl. process), welcher über den Zugriff entscheidet und eine Zugriffskontrolle erzwingt, wobei dies unter der Berücksichtigung einer impliziten Autorisierungsrichtlinie, welche die Herausgabe der Objektreferenz oder URI eines Zielobjekts aus einer Zieldomäne zu einem Initiator aus einer Initiatordomäne mit der Erlaubnis des Zugriffs eines jeden Initiators aus einer Initiatordomäne auf das Ziel verbindet. In diesem Zusammenhang ist eine Zieldomäne eine Menge von Zielen (Objekte oder Ressourcen) in einem einzelnen Anwendungsprozess oder einer Menge von Anwendungsprozessen auf einem einzelnen Host oder auf mehreren Hosts, wobei sie durch eine einheitliche Zugriffskontrolle mit Mitteln der vorliegenden Erfindung geschützt sind. Eine Initiatordomäne ist als ein Anwendungsprozess oder eine Menge von Anwendungsprozessen außerhalb der Zieldomäne, welche auf einem einzelnen Host oder auf mehreren Hosts ausgeführt werden, zu verstehen, wobei für jeden dieser Anwendungsprozesse gilt, daß jede Zugriffsanforderung auf ein Ziel innerhalb einer Zieldomäne durch die Zugriffskontrollentscheidungen nach der vorliegenden Erfindung so behandelt werden, als ob sie vom selben Initiator kämen.
Als zugrundelegende Annahme wird hierbei davon ausgegangen, daß es oftmals die Absicht eines Anwendungsprogrammierers ist, einen Partneranwendungsprozess (d.h. den Initiator) zum Zugriff auf ein gegebenes Objekt oder eine gegebene Ressource (d.h. dem Ziel) durch Übergabe der Objektreferenz oder URI dieses Objekts in einer Nachricht auf Anwendungsebene an den Initiator, implizit zu autorisieren.
Die hier beschriebene Erfindung kombiniert ein Verfahren zur Autorisierung, das sich wie die o.a. implizite Autorisierungsrichtlinie verhält, mit einem Zugriffskontrollverfahren, welches diese Autorisierung erzwingt, indem es Zugriffsanforderungen auf ein Objekt oder eine Ressource entsprechend ausfiltert: Mit dem Verfahren der vorliegenden Erfindung kann jeder Initiator aus einer gegebenen Initiatordomäne nur auf die Ziele aus einer Zieldomäne zugreifen, für die er implizit oder explizit autorisiert wurde. Die Neuheit der hier beschriebenen Erfindung ergibt sich aus der Kombination des Verfahrens für implizite Autorisierung mit einem wirkungsvollen und zuverlässigen Verfahren zur Erzwingung dieser Autorisierung (d.h. abweisen unzulässiger Zugriffsversuche).
Sitzungen
Implizite Autorisierung basiert auf dem Konzept einer Eingangssitzung, welche temporär einen gemeinsamen Kontext für eine Reihe von verschiedenen, zwischen dem Anwendungsprozess einer Initiatordomäne und dem Anwendungsprozess einer Zieldomäne ausgetauschten, Nachrichten definiert, mit dem Ziel einer temporären Beschränkung der Gültigkeit der impliziten Autorisierung. Von allen Nachrichten, bei denen angenommen wird oder bei denen überprüft wurde, daß sie aus der selben konzeptionellen Quelle oder einer beliebigen, unter der selben authentifizierten Kennzeichnung operierenden, Quelle stammen oder die von der Zieldomäne zurück zu der selben konzeptionellen Quelle gesendet werden, wird, unter Berücksichtigung einer zeitlichen Einschränkung, angenommen, daß sie zur selben Eingangssitzung gehören. Diese konzeptionelle Quelle, welche im folgenden Inititatordomäne genannt wird, kann ein einzelner Anwendungsprozess oder eine Menge von Anwendungsprozessen, die auf einem einzelnen Host oder mehreren Hosts ausgeführt werden, sein.
Die Zuweisung einer gegebenen, zwischen einer Initiatordomäne und Zieldomäne ausgetauschten, Nachricht zu einer bestehenden oder neu erzeugten Eingangssitzung mittels des Verfahrens der hier beschriebenen Erfindung kann auf einer Vielzahl, von der konzeptionellen Quelle der Nachricht und dem vorgesehenen Anwendungsgebiet abhängigen, Kriterien basieren, wie z.B.:

– das Ergebnis der Sicherheitstransformationen, das anzeigt, welche Sicherheitsassoziation die kryptographische Transformation der zuzuweisenden Nachricht bestimmte, oder
– der Sicherheitsassoziationskennzeichner (wie z.B. der Sitzungskennzeichner der SSL, TLS oder WTLS Protokolle) der durch irgendein Verfahren mit der Nachricht verbunden ist, oder
– der mit beliebigen Mitteln mit der Nachricht verbundene authentifizierte Kennzeichner (falls vorhanden) des Partner-Anwendungsprozesses (z.B. der Hauptkennzeichner) in der Initiatordomäne, oder
– die IP-Adresse des Partnersystems, oder
– ein beliebiges Sicherheitstoken (Sicherheitskennzeichen) (z.B. ein von dem Initiator generiertes Geheimnis, welches anschließend in der Initiatordomäne mit dem öffentlichen Schlüssel der Zieldomäne verschlüsselt wurde und das daraufhin für einen bestimmten Zeitraum jeder von der Initiatordomäne ausgehenden Anforderungstyp-Nachricht beigefügt wird [Dieses Geheimnis kann zwischen Anwendungen und Hosts innerhalb der Initiatordomäne ausgetauscht werden, mit der Folge, daß die implizite Autorisierung für jede dieser Anwendungen oder jeden dieser Hosts gültig ist oder gültig wird. Außerdem kann es zwischen kooperierenden Zieldomänen ausgetauscht werden; wenn eine erste Zieldomäne eine Referenz oder URI für ein Ziel in einer zweiten, kooperierenden Zieldomäne an einen Initiator (oder einer Anwendung in einer Initiatordomäne) weitergibt, so wird dieser Initiator implizit für den Zugriff auf das Ziel in der zweiten Zieldomäne autorisiert. Kooperation zwischen Zieldomänen bedeutet in diesem Zusammenhang den selektiven Austausch Sitzungskontext-spezifischen Zustands zwischen Zieldomänen.], oder
– eine beliebige, einer Anforderungstyp-Nachricht mittels eines kryptographischen Verfahrens zugewiesene, Art von digitaler Signatur, oder
– einer beliebigen Kombination der o.a Methoden.

Eine Eingangssitzung kann von jedem Anwendungsprozess mit der ersten zu einer Zieldomäne gesendeten Nachricht initiiert werden. Sie existiert für eine bestimmte Zeitperiode bis sie von einem genau bestimmten Ereignis (abhängig von der Eignung in dem speziellen Anwendungsgebiet der Anwendung) beendet wird, wie z.B:

– ein Leerlaufzeitintervall läuft ab (weil innerhalb einer spezifischen Zeitperiode keinerlei, zum Sitzungskontext einer gegebenen Eingangssitzung gehörende, Nachricht ausgetauscht wurde),
– der Empfang einer bestimmten, spezifischen Anforderungsnachricht im Sitzungskontext einer gegebenen Eingangssitzung,
– der Empfang einer Antwortnachricht zu einer bestimmten, spezifischen Anforderungsnachricht im Sitzungskontext einer gegebenen Eingangssitzung,
– der Empfang einer speziellen Steuerungs- oder Verwaltungsnachricht,
– einer beliebigen Kombination des Vorgenannten.

Die Lebensdauer einer Eingangssitzung ist nicht notwendigerweise von der zugrundeliegenden Transportverbindung anhängig. Sie kann sich z.B auf die Lebensdauer einer Sicherheitsassoziation stützen, die durch Sicherheitsprotokolle auf der Transportebene, wie dem Secure Sockets Layer (SSL) Protokoll, dem Transport Layer Security (TLS) Protokoll oder dem Wireless Transport Layer Security (WTLS) Protokoll, welche mehrere verschiedene zugrunde liegende Transportverbindungen umfassen können, gegeben ist.
Im Fall einer, die Authentifizierung eines Partners in einer Initiatordomäne betreffenden, Sicherheitsassoziation hängt die Lebensdauer einer gegebenen Eingangssitzung nicht notwendigerweise von irgendeiner bestimmten Sicherheitsassoziation ab, sondern sie kann sich auf eine Vielzahl, unter Mitwirkung oder von derselben authentifizierten Hauptkennung etablierten, Sicherheitsassoziationen stützen.
Eingangssitzungen & implizite Autorisierung
Das neuartige Verfahren sitzungsbasierter impliziter Autorisierung interpretiert den Vorgang der Übergabe einer Referenz oder URI zu einem Zielobjekt innerhalb einer gegebenen Eingangssitzung durch einen Anwendungsprozess einer Zieldomäne zu einem weiteren Anwendungsprozess in einer Initiatordomäne, als implizite Autorisierung für diese Initiatordomäne zum Zugriff auf oder Abruf dieses Ziels (welches ein beliebiges fernabfragbares Objekt oder eine beliebige fernabfragbare Ressource sein kann) innerhalb der zugehörigen Eingangssitzung.
Mit Bezug auf 1a wird dieser Vorgang durch ein auf konzeptioneller Ebene dargestelltes Beispiel verdeutlicht, in welchem die Initiatordomäne W umfassend den Initiatorhost IH der eine Anforderungstyp-Nachricht M1 zu einem Ziel Target1 auf einem Zielhost TH innerhalb der Zieldomäne TD sendet, wobei diese Nachricht durch das Verfahren der hier beschriebenen Erfindung abgefangen wird. In Abhängigkeit von Informationen bzgl. des Ursprungs der empfangenen Anforderungstyp-Nachricht M1 oder von, vom Ursprung beigefügten, mit der Anforderungstyp-Nachricht M1 assoziierten Information, wird der Anforderungstyp-Nachricht M1 eine Eingangssitzung zugewiesen und der passende Sitzungskontext SC-W zu dieser Eingangssitzung ausgewählt REQ1. Dies geschieht vorzugsweise durch das Nachrichtenursprungsidentifikations/Authentifizierungs-Subsystem MO. Nachdem die Anforderungstyp-Nachricht M1 dem ausgewählten Sitzungskontext SC-W zugewiesen wurde, wird sie über das Zugriffskontrollentscheidungs- & Erzwingungs-Subsystem AC weitergereicht, von dem angenommen wird, daß es, aufgrund einer Überprüfung REQ2 des Sitzungskontext SC-W, den Zugriff auf das adressierte Ziel Target1 gewährt. Die vom Ziel Target1 als Antwort auf die Anforderungstyp-Nachricht M1 erzeugte Antworttyp-Nachricht M10, von der angenommen wird, daß sie eine Referenz oder einen URI auf ein weiteres Ziel Target2 auf dem Zielhost TH in der Zieldomäne TD enthält, wird wiederum von dem Verfahren der hier beschriebenen Erfindung abgefangen, vorzugsweise von einem Subsystem für implizite Autorisierung IA. Die Tatsache, daß eine Referenz oder URI zu einem weiteren Ziel Target2 innerhalb der Nachricht weitergereicht wurde, wird festgestellt und als implizite Autorisierung zum Zugriff auf Ziel Target2 innerhalb der vorliegenden Eingangssitzung bewertet. Diese implizite Autorisierung wird durch (MODIFIZIERE-KONTEXT) REQ3 im Sitzungskontext SC-W vermerkt, bevor die Antworttyp-Nachricht M10 an den Initiatorhost IH der Initiatordomäne W weitergereicht wird.
Im weiteren Verlauf wird, während der Lebensdauer der selben Eingangssitzung, das Verfahren des Zugriffskontrollentscheidungs- & Erzwingungs-Subsystem AC dieser Erfindung diese implizite Autorisierung berücksichtigen und seine Zugriffskontrollentscheidungs- und Erzwingungsfunktion entsprechend ausführen, d.h. Zugriffe auf die Ziele Target1, Target2, welche in genau dieser Eingangssitzung implizit autorisiert wurden und für die eine Zugriffsanforderungsnachricht im Sitzungskontext dieser Eingangssitzung ausgetauscht wurden, werden gestattet. Dies wird durch ein Beispiel auf konzeptioneller Ebene in 1b dargestellt.
In 1b sendet der Initiatorhost IH aus der Initiatordomäne W eine zweite Anforderungstyp-Nachricht, dieses mal zu Ziel Target2 auf Zielhost TH innerhalb der Zieldomäne TD, wobei diese Nachricht mit dem Verfahren der hier beschriebenen Erfindung folgenderweise abgefangen wird: Wiederum wird, in Abhängigkeit von Informationen bzgl. des Ursprungs der Anforderungstyp-Nachricht M1 oder von, vom Ursprung beigefügten, mit der Anforderungstyp-Nachricht M1 assoziierten Informationen, der Anforderungstyp-Nachricht M1 eine Eingangssitzung zugewiesen und der passende Sitzungskontext SC-W zu dieser Eingangssitzung ausgewählt REQ1. Diese Anforderungstyp-Nachricht M1 wird dann an das Zugriffskontrollentscheidungs- & Erzwingungs-Subsystem AC weitergereicht, welches den zugewiesenen Sitzungskontext SC-W auf eine vorhandene implizite Autorisierung zum Zugriff auf Ziel Target2 überprüft. Da Sitzungskontext SC-W vor REQ3 der 1a modifiziert wurde um diese spezielle implizite Autorisierung widerzuspiegeln wird der Zugriff gestattet und die Anforderungstyp-Nachricht M1 zum Ziel Target2 auf Zielhost TH in Zieldomäne TD weitergereicht. Die von Ziel Target2 als Antwort auf Anforderungstyp-Nachricht M1 erzeugte Antworttyp-Nachricht M10 zum Initiatorhost IH in der Initiatordomäne W wird wiederum durch das Verfahren der hier vorliegenden Erfindung abgefangen. Dieses mal wird angenommen, daß die Antworttyp-Nachricht M10 keine Referenz oder URI enthält. Deshalb wird die Nachricht ohne irgendeine Modifikation des Sitzungskontext an Initiatorhost IH der Initiatordomäne W weitergereicht.
Jedweder Zugriffsversuch eines Anwendungsprozesses aus beliebiger Initiatordomäne auf ein bestimmtes Ziel Target1, Target2 auf dem Zielhost TH in der Zieldomäne TD ohne vorherigen Empfang von Referenzen oder URIs auf dieses Ziel Target1, Target2 innerhalb des Sitzungskontexts der gleichen Eingangssitzung wird mit dem Verfahren dieser Erfindung wirksam blockiert. Insbesondere wird jeder Versuch eines Anwendungsprozesses in einer Initiatordomäne zum Zugriff innerhalb eines Sitzungskontexts einer gegebenen Eingangssitzung auf ein bestimmtes Ziel Target1, Target2, dessen Objektreferenz oder URI durch eine Zieldomäne TD auf dem Zielhost TH innerhalb einer weiteren, gleichzeitig bestehenden Eingangssitzung (und damit zu einem weiteren Anwendungsprozess in einer weiteren Initiatordomäne) ausgehändigt wurde, die jedoch nicht innerhalb der erstgenannten Eingangssitzung ausgehändigt wurde, durch die Blockierung der Anforderung abgewiesen. Dies wird durch ein Beispiel auf konzeptioneller Ebene in 1c dargestellt.
In 1c sendet ein weiterer Initiator aus einer weiteren Initiatordomäne Y von einem weiteren Initiatorhost IH eine Anforderungstyp-Nachricht M1 zu einem Ziel Target2 auf dem Zielhost TH innerhalb der Zieldomäne TD, wobei diese Nachricht mit dem Verfahren der hier beschriebenen Erfindung folgenderweise abgefangen wird: In Abhängigkeit von Informationen bzgl. des Ursprungs der empfangenen Anforderungstyp-Nachricht M1 oder von, vom Ursprung beigefügten, mit dieser Anforderungstyp-Nachricht M1 assoziierten Informationen, wird der Anforderungstyp-Nachricht M1 eine bereits bestehende oder eine neu erzeugte Eingangssitzung zugewiesen und der passende Sitzungskontext zu dieser Eingangssitzung. ausgewählt REQ1, in diesem Beispiel Sitzungskontext SC-Y (da hier eine andere Initiatordomäne Y vorliegt und damit auch eine andere Eingangssitzung für diesen Initiator).
Als nächstes wird die Anforderungstyp-Nachricht M1 an das Zugriffskontrollentscheidungs- & Erzwingungs-Subsystem AC weitergereicht, welches den zugewiesenen Sitzungskontext SC-Y auf Vorhandensein einer impliziten Autorisierung zum Zugriff auf Ziel Target2 überprüft REQ2. Da Sitzungskontext Y SC-Y verschieden von Sitzungskontext W SC-W aus 1a, 1b ist, und nur der letztere einen Vermerk für die implizite Autorisierung für Ziel Target2 enthält, wird das Ergebnis der Überprüfung REQ2 von Sitzungskontext SC-Y zum Zugriff auf Ziel Target2 eine Abweisung sein.
Weiterhin wird jeder Zugriffsversuch eines Anwendungsprozesses aus einer Initiatordomäne auf ein bestimmtes Ziel Target1, Target2 außerhalb des durch eine beliebige Eingangssitzung errichteten Kontextes grundsätzlich durch Abweisung des Zugriffs beantwortet. Dies wird durch die Netzwerkarchitektur selbst erzwungen, die sicherstellen muss, daß jeder, den Nachrichtenaustausch betreffender, Netzwerkverkehr durch den Steuerungsprozess einer Ausführung der hier beschriebenen Erfindung geschleust wird, wobei die Weiterleitung einer Anforderung innerhalb des Steuerungsprozesses der hier vorliegenden Erfindung von der Existenz eines passenden Kontextes und der impliziten oder expliziten Autorisierung abhängt.
Um ein Verfahren zum Bootstrapping bereitzustellen muss für die o.a. Regel eine Ausnahme gemacht werden: Entities (Einheiten) können explizit für den Zugriff auf bestimmte Ziele Target1, Target2 innerhalb eines Anwendungsprozesses in der Zieldomäne TD autorisiert werden (unabhängig von jeder Eingangssitzung). Die Gestattung des Zugriffs durch das Zugriffskontrollentscheidungs- & Erzwingungs-Subsystem AC in dem Beispiel aus 1a könnte aufgrund einer expliziten, in einer Zugriffskontrollrichtlinie spezifizierten, Autorisierung erfolgen. In diesem Fall wäre die in 1a dargestellte Überprüfung REQ2 des Sitzungskontexts SC-W überflüssig.
Ziele dieses Typs sind die einzigen Ziele, auf die während der Initiierung einer Eingangssitzung aus einer Initiatordomäne zugegriffen wird. Jede Interaktion mit diesen Zielen kann zur Aushändigung weiterer Objektreferenzen und URIs führen.
Anwendbarkeit
Das System und Verfahren nach der vorliegenden Erfindung ist für jedes der o.a. beschriebenen verteilten Systeme als Zusatzfunktionalität einsetzbar, indem jegliche Anforderungs- und Antwortnachrichten zwischen Anwendungsprozessen innerhalb der Initiatordomäne und den Anwendungsprozessen innerhalb der Zieldomäne abgefangen werden, wobei letztere durch das System und Verfahren der hier beschriebenen Erfindung geschützt werden. Im Allgemeinen können diese Anforderungs- und Antwortnachrichten an einem zentral gelegenen, nicht umgehbaren, strategischen Punkt des Netzwerks (z.B. eine zwischengeschaltete Zugriffskontrolle, die innerhalb einer Gateway-Maschine realisiert ist) oder innerhalb jeder individuell zu schützenden Server-Maschine abgefangen und verarbeitet werden. Ein Beispiel einer Netzwerktopologie und eines verteilten Systems ist in 2 und 3 dargestellt und wird im folgendem beschrieben.
Vorzugsweise Ausführungsform der vorliegenden Erfindung
Im folgendem werden bevorzugte Ausführungsformen der hier vorliegenden Erfindung als (i) Gateway auf Anwendungsebene und als (ii) als Interzeptor auf Anwendungsebene beschrieben.
In 2 wird ein Beispiel einer Netzwerktopologie dargestellt. In diesem Beispiel wird eine Gateway-Maschine GWM gezeigt, die zwei sonst vollständig getrennte Netzwerke verbindet: ein internes Netzwerk IN das logisch nur über die Gateway-Maschine GWM mit einem externen Netzwerk EN verbunden ist.
Eine an einem externen Netzwerk EN angeschlossene Client-Maschine 1 CM1 kann Anforderungstyp Anwendungsebenenprotokollelemente zu einer Server-Maschine 1 SM1 senden und kann Antworttyp Anwendungsebenenprotokollelemente von der Server-Maschine 1 SM1 empfangen. Alternativ kann die Client-Maschine 1 SM1 Anwendungsebenenprotokollelemente über die Gateway-Maschine GWM mit einer beliebigen, an das interne Netzwerk angeschlossenen, Server-Maschine austauschen, wie z.B. Server-Maschine 2 SM2 oder Server-Maschine 3 SM3. Eine weitere Client-Maschine 2 CM2, welche direkt an das interne Netzwerk IN angeschlossen ist, kann Anwendungsebenenprotokollelemente direkt mit der Server-Maschine 2 SM2 oder der Server-Maschine 3 SM3 ohne Verwendung der Gateway-Maschine GWM austauschen.
Die in 2 dargestellte spezifische Konfiguration ist nur als Beispiel gedacht und soll nicht als Einschränkung der Netzwerktopologien, auf die diese Erfindung angewendet werden kann, verstanden werden. Zum Beispiel können Paketfilter (screening)-Router (in 2 nicht dargestellt) auf dem Weg zwischen dem externen Netzwerk EN und der Gateway-Maschine GWM (d.h externe Router) und zwischen dem internen Netzwerk IN und der Gateway-Maschine GWM (d.h. interne Router) vorhanden sein, welche den direkten Datenaustausch auf Netzwerkebene zwischen dem externen Netzwerk EN und dem internen Netzwerk IN verhindern. Ohne solche Paketfilter- Router muss die Gateway-Maschine als dual-homed (in zwei Netzwerken beheimatet) Host ausgeführt werden der Netzwerkpakete nicht zwischen diesen Netzen „routed" (vermitteln im Sinne der spezifischen Funktion eines Routers) (d.h. hier nicht einfach weiterleitet). Normalerweise nimmt die Gateway-Maschine die Rolle eines Proxy-Servers in jeder der in Chapman (Chapman, D., Zwicky, E. „Building Internet Firewalls". O'Reilly & Assoc. Inc., 1995) beschriebenen Firewall Architekturen ein, wie z.B. die dual-homed Host Architektur, die screened (abgeschirmter) Host Architektur, die screened Subnet (abgeschirmtes Teilnetz) Architektur und ihrer Variationen wie eine zusammengefasster interner/ externer Router mit einem zusätzlichen Perimeter-Netzwerk, an das die Gateway-Maschine GWM mittels einer dedizierten Netzwerkschnittstelle angeschlossen ist. In allen Fällen, in der die Gateway-Maschine die Rolle eines Proxy-Servers einnimmt, muss die Konfiguration der benachbarten (möglicherweise Paketfilter-) Router sicherstellen, daß jeder Netzwerkverkehr vom externen Netzwerk EN in das interne Netzwerk IN, oder umgekehrt, die Gateway-Maschine GWM durchläuft. Im Allgemeinen sollte die Netzwerktopologie des internen Netzwerks IN und der Gateway-Maschine GWM so gewählt werden, daß das interne Netzwerk isoliert ist, d.h. es gibt nur eine einzige Verbindung zu dem externen Netzwerk EN oder anderen außerhalb liegenden Netzwerken, die über die Gateway-Maschine GWM führt. Diese Topologie erzwingt die erforderliche Einschränkung, daß jede Art von Netzwerkkommunikation zwischen internen Netzwerk IN und externen Netzwerk EN über einen einzigen Kontrollpunkt läuft, d.h über die Gateway-Maschine GWM.
In 3 wird die Beispielnetzwerktopolgie aus 2 gezeigt, in der die hier beschriebene Erfindung installiert wurde. Gemeinsame Elemente aus 2 werden mit derselben Bezeichnung dargestellt. Obwohl die hier vorliegende Beschreibung einen einfachen unidirektionalen Fall mit einer Client-Maschine in dem externen Netzwerk, die versucht auf eine Anwendung auf einem Server in einem internen Netzwerk zuzugreifen, annimmt, ist diese Erfindung auch auf komplexere Szenarien mit Anwendungen, die sowohl die Clientrolle als auch die Serverrolle wahrnehmen, anwendbar.
Das interne Netzwerk IN in 3 ist vom externen Netzwerk EN mittels einer, nach dem Verfahren der hier beschriebene Erfindung aufgebauten, Gateway-Maschine GWM separiert und geschützt. Es wird weiterhin angenommen das, außer dem Weg über die Gateway-Maschine GWN, kein weiterer Pfad zwischen dem internen Netzwerk IN und dem externen Netzwerk EN existiert. Die Gateway-Maschine GWM arbeitet als Gateway auf Anwendungsebene (auch Proxy-Server genannt) und autorisiert und kontrolliert den Zugriff von Client-Maschinen im externen Netzwerk EN zu allen, von der Anwendung APP2, APP3 im internen Netzwerk IN bereitgestellten, Ressourcen oder Objekten. Im folgendem werden diese Ressourcen Ader Objekte (wie z.B. CORBA Objekte, Java Objekte, DCOM Objekte oder beliebiger statisch oder dynamisch erzeugter HTML, XML oder WML Inhalt) generell Ziele genannt. Sie sind in 3 als Target1, Target2 und Target3 bezeichnet.
Spezifischer gesagt, realisiert innerhalb der Gateway-Maschine GWM ein, nach dem Verfahren der hier vorliegenden Erfindung aufgebautes, Gateway auf Anwendungsebene ALG das Verfahren zur impliziten Autorisierung und Zugriffskontrolle. Das Gateway auf Anwendungsebene ALG konsumiert die vom ersten, auf tiefer Ebene ablaufenden, Protokollstapel LL1 von einer Client-Maschine 1 CM1 im externen Netzwerk EN empfangenen Anforderungstyp Anwendungsebenenprotokollelemente und verarbeitet diese Protokollelemente gemäß der hier vorliegenden Erfindung, was die Ausführung der Zugriffskontrolle umfaßt, wobei letztere in genau einer der folgenden zwei Alternativen resultiert: (i) das verarbeitete Anforderungstyp-Anwendungsebenenprotokollelement wird, um es zum Ziel, das von einer der Anwendungen APP2, APP3 auf der Server-Maschine 2 oder 3 SM2, SM3 innerhalb des internen Netzwerks IN verwaltet wird, weiterzureichen, an den zweiten, auf tiefer Ebene ablaufenden, Protokollstapel LL2 übergeben (d.h. der Zugriff wird gewährt) – oder – (ii) das empfangene Anwendungsebenenprotokollelement wird blockiert und übersprungen, wobei ein neues Antworttyp-Anwendungsebenenprotokollelement erzeugt wird oder nicht um es an den ersten, auf tiefer Ebene ablaufenden, Protokollstapel LL1 zur Rückgabe an den ursprünglichen Anfrager auf der Client- Maschine 1 CM1 aus dem externen Netzwerks EN weiterzureichen (d.h. der Zugriff wird verweigert). Werden vom Gateway auf Anwendungsebene ALG die vom zweiten, auf tiefer Ebene ablaufenden, Protokollstapel LL2 empfangenen und ursprünglich von einer der Anwendungen 2 oder 3 APP2, APP3 der Server-Maschine 2 oder 3 SM2, SM3 im internen Netzwerk IN stammenden Antworttyp-Anwendungsebenenprotokollelemente verarbeitet, so geschieht diese Verarbeitung dieser Anwendungsebenenprotokollelemente gemäß der hier vorliegenden Erfindung und kann eine implizite Autorisierung für weitere objektbasierte Ressourcen (d.h. Ziele) umfassen.
Wie in 3 dargestellt, kann die hier vorgestellte Erfindung nicht nur als Gateway auf Anwendungsebene auf der Gateway-Maschine GWM ausgeführt werden (dies ist die bevorzugte, im folgendem beschriebene, Ausführungsform als Gateway auf Anwendungsebene), sondern sie kann auch alternativ als Interzeptor auf Anwendungsebene ALI direkt auf einer Server-Maschine SM1, SM2 ausgeführt werden um individuelle Anwendungen APP1, APP2 durch die Durchführung der Autorisierungs- und Zugriffskontrolle, sobald ein Zugriff auf beliebige objektbasierte Ressourcen (d.h. Ziele Target1, Target2) der Anwendungen APP1, APP2 versucht wird, zu schützen. In dieser Ausführungsform werden Anforderungstyp- oder Antworttyp-Anwendungsebenenprotokollelemente, die von dem, auf tiefer Ebene ablaufenden, Protokollstapel LL2, gesendet oder empfangen werden, von dem Interzeptor auf Anwendungsebene ALI in einer dem Verfahren ALG ähnlichen Weise verarbeitet.
Wie in 3 dargestellt wird, kontrolliert die Gateway-Maschine GWM den Zugriff jedes Clients aus dem externen Netzwerk EN, z.B. die als Initiatorhost IH arbeitende Client-Maschine 1 CM1 beim Zugriff auf jedwede objektbasierte Ressource (d.h. Ziele Target2, Target3) innerhalb der Anwendung APP2, APP3 auf die, als Zielhost TH arbeitende, Server-Maschine 2 oder 3 SM2, SM3. Zusätzlich wird die Anwendung 2 APP2 auf Server-Maschine 2 durch eine weitere Ausführung dieser Erfindung (d.h. als Interzeptor auf Anwendungsebene ALI) geschützt, welche die Kontrolle des Zugriffs von jedem internen Client im internen Netzwerk IN, wie z.B. Client-Maschine 2 CM2, auf jedwede objektbasierte Ressource innerhalb Anwendung 2 APP2, wie z.B Ziel Target2, ermöglicht. Analog hierzu wird die Anwendung 1 APP1 auf der, direkt am externen Netzwerk EN angeschlossen, als Zielhost TH arbeitenden Server-Maschine 1 SM1 durch dieselbe Ausführung der hier beschrieben Erfindung (d.h. als Interzeptor auf Anwendungsebene ALI) geschützt, welche die Zugriffskontrolle für jeden externen Client aus einem externen Netzwerk EN, wie z.B. der Client-Maschine 1 CM1 auf jede objektbasierte Ressource, wie z.B. Ziel Target1, in Anwendung 1 APP1 ermöglicht. Eine solche, als weiterer Zielhost TH arbeitende, Server-Maschine 1 SM1 kann z.B ein Web-Server innerhalb des screened Subnets oder des Perimeter-Netzwerks, auf den direkt aus dem öffentlichem Internet zugegriffen werden kann, sein.
Die, auf tiefer Ebene ablaufenden, Protokollstapel LL1, LL2 können jedes IP-basierte, auf Transportebene arbeitende, Protokoll wie TCP/IP oder UDP/IP sowohl mit als auch ohne Verschlüsselung auf Transportebene, wie z.B. SSL oder TLS, oder andere, auf Transportebene arbeitende, Protokolle, wie das, durch das WAP Forum definierte, Wireless Datagramm Protokoll (WDP) mit oder ohne Wireless Transport Layer Security (WTLS) oder eine beliebige Kombination dieser, wie z.B. WTLS über UDP/IP, implementieren. Diese o.a. Protokolle sind hier nur beispielhaft aufgeführt und sollen nicht als Einschränkung der möglichen, auf Transportebene arbeitenden, Protokolle, auf die diese Erfindung angewendet werden kann, verstanden werden. Im Fall von verbindungsbasierten, auf Transportebene arbeitenden, Protokollen würden die, auf tiefer Ebene ausgeführten, Protokollstapel auch die Annahme und/oder Herstellung der Verbindung auf Transportebene durchführen, so wie dies typischerweise von jeder Client- oder Server-Anwendung getan wird. Innerhalb der Gateway-Maschine GWM können die beiden, auf tiefer Ebene ablaufenden, Protokollstapel LL1, LL2 sowohl eine gemeinsame als auch eine unterschiedliche Implementation zur Steuerung einer oder mehrerer Netzwerkschnittstellenkarten verwenden.
Im folgenden werden die Begriffe „Anwendungsebene" und „Transportebene" in der durch die IP Protokollsammlung vorgegebenen Bedeutung verwendet. Dem Fachmann wird die Abbildung der Beschreibung dieser Erfindung auf die Ebenen eines OSI basierten Protokollstapels einfach möglich sein.
Ausführung als Gateway auf Anwendungsebene
Die 4a zeigt als Blockdiagramm die Ausführungsform der hier beschriebenen Erfindung als ein, in eine Gateway-Maschine (wie die in 4 dargestellte GWM) integriertes, Gateway auf Anwendungsebene ALG. Ein Gateway auf Anwendungsebene ist ein Programm, das Anforderungen aus einem Netzwerk annimmt und diese Anforderungen mittels Nutzung eines anderen Netzwerks erfüllt. Es kann für die Entscheidung wohin eine Nachricht gesendet werden soll eine Datenbank von Zielen abfragen. Im Allgemeinen ist es nötig eine Nachricht, die durch ein Anwendungs-Gateway oder einen Proxy von einem Netzwerk in ein anderes weitergereicht wird, zu übersetzen (z.B. Umformatierung des Nachrichtenkopfs).
Obwohl die im folgendem diskutierten Prinzipien der hier beschriebenen Erfindung für objektbasierte Systeme im Allgemeinen (wie zuvor erläutert) relevant sind werden diese oft, um eine Vereinfachung der Beschreibung zu erreichen, auf Basis des spezifischen Falls einer, eine CORBA Brücke für das IIOP Protokoll ausführenden, Gateway-Maschine, welche unter Berücksichtigung der hier vorgestellten Erfindung mit der Unterstützung für die implizite Autorisierung und Zugriffskontrolle für CORBA-basierte verteilte Systeme verbessert wurde, vorgestellt. Der Fachmann wird jedoch erkennen, daß die Prinzipien auf ein erweitertes Umfeld anwendbar sind, z.B. auf verteilte Systeme die auf Protokollen wie Java RMI, DCOM, HTTP/ HTML, HTTP/XML, SOAP oder WAP/ WML basieren.
Die hier vorgestellte Erfindung, besteht, wie in 4 dargestellt, aus einer Anzahl von Subsystemen (in dem Blockdiagramm dargestellt als Blöcke) die in einer oder mehreren Anwendungen auf einem oder mehreren Hosts ausgeführt werden. Die Gruppierung der Verfahren der hier vorgestellten Erfindung ist nur beispielhaft zum Zwecke der Illustration durchgeführt – möglich ist auch eine andere Verteilung, Zusammenfassung oder weitere Aufteilung der beschriebenen Subsysteme oder sogar die Replikation oder Duplizierung. Des weiteren kann jedes der im folgendem beschriebenen Verfahren durch Zwischenspeicherung optimiert werden, wodurch bestimmte Zwischenschritte redundant oder auf andere Subsysteme verlagert werden. Diese Optimierungsmöglichkeiten werden hier zur Verbesserung der Verständlichkeit dieses Dokuments nicht beschrieben.
4a zeigt einen Initiatorhost IH (wie die Client-Maschine 1 CM1 aus 2) aus einem externen Netzwerk (wie das externe Netzwerk EN aus 2), der über ein Gateway auf Anwendungsebene ALG auf einer Gateway-Maschine GWM mit einem Zielhost TH aus dem internen Netzwerk (wie das interne Netzwerk IN aus 2) interagiert. Interaktionen des Gateways auf Anwendungsebene ALG mit dem Initiatorhost IH im externen Netzwerk werden auf der Gateway-Maschine GWM vom, auf tiefer Ebene ablaufenden, Protokollstapel LL1 ausgeführt, während die Interaktionen des Gateways auf Anwendungsebene ALG mit dem Zielhost TH im internen Netzwerk auf der Gateway-Maschine GWM vom, auf tiefer Ebene ablaufenden, Protokollstapel LL2 ausgeführt werden. Beide, auf tiefer Ebene ablaufenden, Protokollstapel LL1, LL2 übernehmen die Verarbeitung des, auf Transportebene ablaufenden, Protokolls während des Austauschs von TCP Segmenten oder Datagrammen mit dem Initiatorhost IH oder dem Zielhost TH. Zusätzlich kann jeder der, auf tiefer Ebene ablaufenden, Protokollstapel LL1, LL2 die Verarbeitungsschritte, die sich aus den Sicherheitsverfahren der Transportebene (wie z.B. SSL, TLS oder WTLS) ergeben, falls verschlüsselte TCP Segmente oder Datagramme ausgetauscht werden, übernehmen.
Das Gateway auf Anwendungsebene ALG ist als Zusammenstellung einer Anzahl von Software-Subsystemen (ein Nachrichtenursprungsidentifikations/Authentifizierungs-Subsystem MO, ein Zugriffskontrollentscheidungs- & Erzwingungs-Subsystem AC, ein Subsystem für implizite Autorisierung IA, ein Proxy-Server Subsystem PS und ein Sitzungskontextverwaltungs-Subsystem SCM) welche miteinander oder mit den beiden, auf tiefer Ebene ablaufenden, Protokollstapeln LL1, LL2 interagieren, indem sie Datenelemente mittels einer, der Socket-Schnittstelle ähnlichen, Anwendungsprogrammierschnittstelle API1, API2, API3, API4, API5 austauschen, dargestellt.
Eine vom Initiatorhost IH zum Gateway auf Anwendungsebene ALG gesendete Anforderungstyp-Nachricht M1 wird vom, auf tiefer Ebene ablaufenden, Protokollstapel LL1 akzeptiert (wobei optional Sicherheitstransformationen unter Zugrundelegung des verwendeten Sicherheitsprotokolls der Transportebene angewendet werden) und über die Anwendungsprogrammierschnittstelle API1 als ein (nicht verschlüsseltes) Datenelement M2 zusammen mit einem Deskriptor D (welcher entweder eine mit diesem Datenelement assoziierte Verbindung oder ein mit diesem Datenelement assoziiertes Socket-Paar beschreibt) an das Nachrichtenursprungsidentifikations/Authentifizierungs-Subsystem MO weitergereicht. Zusätzlich wird eine beliebige Art von, mit dem Deskriptor D assoziierte, Ursprungsinformation, wie z.B. die, von dem, auf tiefer Ebene ablaufenden, Protokollstapel LL1 gesammelte IP Adresse des Partners oder das Sitzungs-ID des Sicherheitsprotokolls der Transportebene, über die Anwendungsprogrammierschnittstelle API1 bereitgestellt.
Der von den, auf tiefer Ebene ablaufenden, Protokollstapeln LL1 oder LL2 entweder einer angenommenen Verbindung auf Transportebene (falls TCP/IP oder ein anderes Verbindungsbasiertes Protokoll auf Transportebene verwendet wird) oder einer gesicherten Verbindung (falls ein Verbindungsbasiertes Sicherheitsprotokoll wie SLL, TLS oder WTLS verwendet wird) oder den beiden Kommunikationsendpunkten (d.h. Sockets) des/der ausgetauschten Datagramms/Datagramme (falls UDP/IP oder WDP verwendet wird) zugewiesene Deskriptor D wird während der vollständigen Ablaufkette der Interaktionen von dem, auf tiefer Ebene ablaufenden, Protokollstapel LL1 zu dem, auf tiefer Ebene ablaufenden, Protokollstapel LL2 als ein Mittel zur Bezeichnung der Kommunikationsendpunkte (oder, falls existent, einer Verbindung mit dem Partner) der Partner (z.B. Initiatorhost IH oder Zielhost TH) verwendet. Dieser, von dem, auf tiefer Ebene ablaufenden, Protokollstapel LL1 zugewiesene, Deskriptor D, wird im weiteren Verlauf von den Subsystemen AC, IA, PS zur Referenzierung des Kommunikationsendpunkts des Partners verwendet.
Das Nachrichtenursprungsidentifikations/ Authentifizierungs-Subsystem MO erhält das Datenelement M2 mittels der Anwendungsprogrammierschnittstelle API1 vom, auf tiefer Ebene ablaufenden, Protokollstapel LL1 und fragt (unter Verwendung des Deskriptors D, der mit dem, mittels der Anwendungsprogrammierschnittstelle API1 erhaltenen, Datenelement M2, assoziiert ist) jede, für das erhaltene Datenelement verfügbare, zugehörige Ursprungsinformation (ORI) ab.
Sobald eine neue Verbindung akzeptiert wurde (falls ein Verbindungsbasiertes Protokoll auf Transportebene verwendet wird – andernfalls für jedes akzeptierte Datagramm) ruft das Nachrichtenursprungsidentifikations/Authentifizierungs-Subsystem MO das Sitzungskontextverwaltungs-Subsystem SCM mit einer „SELEKTIERE-KONTEXT" Anforderung REQ1 auf, welche das Sitzungskontextverwaltungs-Subsystem SCM bittet den Deskriptor D unter Verwendung der, vom Nachrichtenursprungsidentifikations/ Authentifizierungs-Subsystem MO bereitgestellten, Ursprungsinformationen mit einem vorhanden passenden Sitzungskontext, oder falls ein solcher nicht existiert, mit einem neu erzeugten Sitzungskontext zu korrelieren. Dieser Sitzungskontext wird im folgendem mit Sitzungskontext SC-W bezeichnet.
Das Sitzungskontextverwaltungs-Subsystem SCM verwaltet den Zustand aller (möglicherweise gleichzeitig existierender) Eingangssitzungen als eine variable Anzahl von Sitzungskontextelementen SC-U, SC-W, SC-Y, wobei jedes dieser Sitzungskontextelemente SC-U, SC-W, SC-Y den Zustand einer gegebenen, als Eingangssitzung SC-U, SC-W, SC-Y bezeichneten, Eingangssitzung verwaltet. Deshalb wird angenommen, daß der, den vollständigen Zustand einer gegebenen Eingangssitzung W umfassende, Sitzungskontext SC-W innerhalb des Sitzungskontextdatenelements SC-W verwaltet wird. Das Sitzungskontextverwaltungs-Subsystem SCM verwaltet die Erzeugung und Löschung jedes Sitzungskontextdatenelements SC-U, SC-W, SC-Y, wobei die Löschung durch den Ablauf eines Leerlaufzeitintervalls, anderen Ereignissen oder einem expliziten Verwaltungseingriff ausgelöst wird. Die intern ausgeführten Verfahren des Sitzungskontextverwaltungs-Subsystems SCM werden im folgendem detaillierter in 9, 10, 11, 12 und 13 dargestellt.
Während der Bearbeitung der „SELEKTIERE-KONTEXT" Anforderung REQ1 vom Nachrichtenursprungsidentifikations/Authentifizierungs-Subsystem MO vergleicht das Sitzungskontextverwaltungs-Subsystem SCM die, durch das Nachrichtenursprungsidentifikations/Authentifizierungs-Subsystem MO mit dieser Anfrage bereitgestellten, Ursprungsinformationen mit, innerhalb der Sitzungskontextdatenelemente SC-U, SC-W, SC-Y verwalteten, kennzeichnenden Werten und selektiert entweder das zur bereitgestellten Ursprungsinformation passende oder erzeugt ein neues Sitzungskontextdatenelement. Der bereitgestellte Deskriptor D wird in beiden Fällen als temporärer Verweis zu den selektierten bzw. erzeugten Sitzungskontextdatenelement SC-U, SC-W, SC-Y gespeichert.
Nachdem der Kontrollfluss vom Sitzungskontextverwaltungs-Subsystem SCM zum Nachrichtenursprungsidentifikations/Authentifizierungs-Subsystem MO zurückgegeben wurde, werden die Informationen aus Datenelement M2 (oder einer Sequenz von Datenelementen M2, die Segmente der Transportebene oder Datagramme enthalten) vom Nachrichtenursprungsidentifikations/Authentifizierungs-Subsystem MO zu einem, genau eine Anforderungstyp-Nachricht oder genau eine Antworttyp-Nachricht enthaltendem, Datenelement M3 zusammengestellt und dann das Datenelement M3 über die Anwendungsprogrammierschnittstelle API2 zusammen mit dem gleichen Deskriptor D an das Zugriffskontrollentscheidungs- & Erzwingungs-Subsystem AC übergeben. Die von MO ausgeführten Verfahren werden im folgendem detaillierter in 5a und 5b dargestellt.
Das Zugriffskontrollentscheidungs- & Erzwingungs-Subsystem AC erhält (unter Verwendung der Anwendungsprogrammierschnittstelle API2) vom Nachrichten ursprungsidentifikations/Authentifizierungs-Subsystem MO das, eine Anforderungstyp-Nachricht oder Antworttyp-Nachricht enthaltende, Datenelement M3. Ein Deskriptor D ist mit dem über die Anwendungsprogrammierschnittstelle API2 erhaltenen Datenelement M3 assoziiert. Das Zugriffskontrollentscheidungs- & Erzwingungs-Subsystem AC übergibt jede Antworttyp-Nachrichten enthaltende Datenelemente direkt an das Subsystem für implizite Autorisierung IA, während Anforderungstyp-Nachrichten enthaltene Datenelemente einem Zugriffskontroll- und Erzwingungs-Verfahren unterzogen werden (dies wird in 6a detailliert dargestellt). Während dieser Verarbeitung ruft das das Zugriffskontrollentscheidungs- & Erzwingungs-Subsystem AC das Sitzungskontextverwaltungs-Subsystem SCM mit einer „ÜBERPRÜFE-KONTEXT" Anforderung REQ2 auf, in der das Sitzungskontextverwaltungs-Subsystem SCM beauftragt wird, den vom registrierten Deskriptor D referenzierten Sitzungskontext SC-W zu überprüfen, ob die mittels des erhaltenen Datenelements M3 ausgeführte Anforderung schon vorher implizit autorisiert wurde.
Ergibt sich aus dem vom Sitzungskontextverwaltungs-Subsystem SCM erhaltenen Ergebnis der Überprüfung REQ2, daß eine implizite Autorisierung innerhalb des referenzierten Sitzungskontext SC-U, SC-W, SC-Y gefunden wurde (d.h. der Zugriff wird gestattet), so übergibt das Zugriffskontrollentscheidungs- & Erzwingungs-Subsystem AC ein, die Anforderungstyp-Nachricht enthaltendes, Datenelement M4 über die Anwendungsprogrammierschnittstelle API3 an das Subsystem für implizite Autorisierung IA. Der mit dem Datenelement M3 an der Anwendungsprogrammierschnittstelle API2 assoziierte Deskriptor D ist auch mit dem Datenelement M4 an der Anwendungsprogrammierschnittstelle API3 assoziiert.
Ergibt sich aus dem vom Sitzungskontextverwaltungs-Subsystem SCM erhaltenen Ergebnis der Überprüfung REQ2, daß eine implizite Autorisierung innerhalb des referenzierten Sitzungskontext SC-U, SC-W, SC-Y nicht gefunden wurde (d.h. der Zugriff soll nicht gestattet werden), so wird vom Zugriffskontrollentscheidungs- & Erzwingungs-Subsystem AC das Datenelement M3 entweder einfach verworfen ohne es an das Subsystem für implizite Autorisierung IA zu übergeben, oder es erzeugt ein neues, eine Ausnahmetyp-Nachricht enthaltendes, Datenelement zur Rückgabe an den Initiatorhost IH.
Das Subsystem für implizite Autorisierung IA erhält vom Zugriffskontrollentscheidungs- & Erzwingungs-Subsystem AC (unter Verwendung der Anwendungsprogrammierschnittstelle API3), Anforderungstyp- oder Antworttyp-Nachrichten enthaltende, Datenelemente M4 und reicht diese Anforderungstyp- als auch Antworttyp-Nachrichten über die Anwendungsprogrammierschnittstelle API4 an das Proxy-Server Subsystem PS als Datenelemente M5 weiter. Der mit dem Datenelement M4 an der Anwendungsprogrammierschnittstelle API3 assoziierte Deskriptor D ist auch mit dem Datenelement M5 an der Anwendungsprogrammierschnittstelle API4 assoziiert. Die durch das Subsystem für implizite Autorisierung IA durchgeführte interne Verarbeitung (die sich auf die vom Proxy-Server Subsystem PS erhaltenen Datenelemente richtet) wird im folgendem detaillierter in 7a und 7b dargestellt.
Das Proxy-Server Subsystem PS stellt die Funktionalität eines typischen Proxy-Servers auf Anwendungsebene wie einem HTTP (reverse) Proxy-Server oder eine CORBA IIOP Brücke zur Verfügung. Das Proxy-Server Subsystem PS erhält, Anforderungstyp- oder Antworttyp-Nachrichten enthaltende, Datenelemente M5 vom Subsystem für implizite Autorisierung IA unter Verwendung der Anwendungsprogrammierschnittstelle API4 und übergibt diese Anforderungstyp- und Antworttyp-Nachrichten (nach der für die Proxy-Server Funktionalität erforderlichen Verarbeitung) als Datenelemente M6, unter Verwendung der Anwendungsprogrammierschnittstelle API5 des, auf tiefer Ebene ablaufenden, Protokollstapel LL2, an den, auf tiefer Ebene ablaufenden, Protokollstapel LL2 damit diese Anforderungstyp- oder Antworttyp-Nachrichten als Datenelemente M7 an den Zielhost TH geliefert werden.
Die Antworttyp-Nachrichten M8 werden vom Zielhost TH an den, auf tiefer Ebene ablaufenden, Protokollstapel LL2 geliefert, vom Proxy-Server Subsystem PS als Datenelement M9 vom, auf tiefer Ebene ablaufenden, Protokollstapel LL2 erhalten und als neu erzeugtes Datenelement M10 mittels der, vom Subsystem für implizite Autorisierung IA bereitgestellten, Anwendungsprogrammierschnittstelle API4 an das Subsystem für implizite Autorisierung IA weitergereicht. Vom, auf tiefer Ebene ablaufendem, Protokollstapel LL2 erhaltene Anforderungstyp-Nachrichten des Zielhosts TH können (nach der üblichen, Proxy-Server-artigen, Verarbeitung durch das Proxy-Server Subsystem PS) direkt zum, auf tiefer Ebene ablaufendem, Protokollstapel LL1 zur Lieferung an die zugehörige (z.B. Callback [Rückruf]) Schnittstelle des Initiatorhosts IH weitergereicht werden. Deren Verarbeitung ist nicht Gegenstand der hier beschriebenen Erfindung. Die vom Proxy-Server Subsystem PS durchgeführte Verarbeitung kann mittels dem Fachmann bekannter derzeitiger Technologie geschehen und wird deshalb nicht detailliert beschrieben.
Nach dem Erhalt des Datenelements M10 mit einer Anforderungstyp- oder Antworttyp-Nachricht über die Anwendungsprogrammierschnittstelle API4 vom Proxy-Server Subsystem PS verarbeitet das Subsystem für implizite Autorisierung IA das Datenelement M10 wie in 7b dargestellt um nach jeder/jeden Objektreferenzen) oder URI(s) die entweder als Parameter von Datenelement M10 oder im Körper von Datenelement M10 vorhanden ist/sind zu suchen. Im Fall das Objektreferenzen) oder URI(s) gefunden wurden, ruft das Subsystem für implizite Autorisierung IA das Sitzungskontextverwaltungs-Subsystem SCM mit einer „MODIFIZIERE-KONTEXT" Anforderung REQ3 auf, in dem das Sitzungskontextverwaltungs-Subsystem SCM aufgefordert wird das/die in der Antworttyp-Nachricht M10 gefundenen Objektreferenzen) oder URI(s) zu registrieren. Diese Registrierung führt zu einem Sitzungskontext, der zur Speicherung der zusätzlichen Referenzen) und URI(s) modifiziert und von dem Deskriptor D referenziert wird, der mit dem an der Anwendungsprogrammierschnittstelle API4 erhaltenen Datenelement M10 assoziiert ist.
Danach wird unter Verwendung der Anwendungsprogrammierschnittstelle API3 die Anforderungstyp- oder Antworttyp-Nachricht vom Subsystem für implizite Autorisierung IA als Datenelement M11 an das Zugriffskontrollentscheidungs- & Erzwingungs-Subsystem AC (unter Verwendung der Anwendungsprogrammierschnittstelle API3) und vom Zugriffskontrollentscheidungs- & Erzwingungs-Subsystem AC als Datenelement M12 an das Nachrichtenursprungsidentifikations/Authentifizierungs-Subsystem MO (unter Verwendung der Anwendungsprogrammierschnittstelle API2) und vom Nachrichtenursprungsidentifikations/Authentifizierungs-Subsystem MO als Datenelement M13 an den, auf tiefer Ebene ablaufenden, Protokollstapel LL1 (unter Verwendung der Anwendungsprogrammierschnittstelle API1) weitergereicht, um sie an den Initiatorhost IH zu liefern.
Die intern vom Subsystem AC und Subsystem MO durchgeführte Verarbeitung wird im folgendem detaillierter in 5a, 5b, 6a und 6b dargestellt.
Falls der Initiatorhost IH auch Rückrufe (Callbacks) unterstützt (z.B. der Initiatorhost IH ist selbst Server für andere Zielressourcen) und der Zielhost TH irgendwelche Anforderungstyp-Nachrichten an den Initiatorhost IH schickt, so wird diese Interaktion nicht durch irgendeines der Subsysteme Subsystem für implizite Autorisierung IA, Zugriffskontrollentscheidungs- & Erzwingungs-Subsystem AC, Nachrichtenursprungsidentifikations/Authentifizierungs-Subsystem MO oder Sitzungskontextverwaltungs-Subsystem SCM beeinflusst. Es kann vielmehr jedes von dieser Interaktion betroffene Datenelement einfach vom Subsystem für implizite Autorisierung IA, Zugriffskontrollentscheidungs- & Erzwingungs-Subsystem AC und Nachrichtenursprungsidentifikations/Authentifizierungs-Subsystem MO durchgereicht werden. Diese Interaktionen sind nicht Gegenstand der hier beschriebenen Erfindung.
Ausführung als Interzeptor auf Anwendungsebene
Die Abbildung in 4b zeigt die hier vorliegenden Erfindung in einer Ausführung als Interzeptor auf Anwendungsebene ALI, welcher direkt innerhalb der, die zu schützende Anwendung ausführende, Servermaschine (wie die in 3 dargestellte Servermaschine SM1, SM2) implementiert ist.
Der in dieser Abbildung gezeigte Interzeptor auf Anwendungsebene ALI ist zwischen der zu schützenden Anwendung APP und dem, auf tiefer Ebene ablaufenden, Protokollstapel LL1 platziert. Hier interagiert das oben dargestellte Subsystem für implizite Autorisierung IA anstelle mit einem Proxy-Server PS direkt mit der zu schützenden Anwendung APP. Blöcke die mit der selben Bezeichnung wie in 4a dargestellt werden führen eine identische Verarbeitung aus und spielen die selbe Rolle im Gesamtsystem. Da die Ausführungsform als Interzeptor auf Anwendungsebene weitestgehend identisch mit der im 4a dargestellten Ausführungsform als Gateway auf Anwendungsebene ist und die wichtigsten Unterschiede oben beschrieben wurden konzentriert sich die detailliertere Beschreibung der vorteilhaften Ausführungsform auf den (etwas komplizierteren) Fall der Ausführung als Gateway auf Anwendungsebene.
Im folgendem wird jedes der oben vorgestellten Subsysteme detaillierter beschrieben.
Auf tiefer Ebene ablaufender Protokollstapel
Die, auf tiefer Ebene ablaufenden, Protokollstapel LL1, LL2 sind Protokollstapel der Transportebene, die ein IP-basiertes, auf Transportebene arbeitendes, Protokoll wie TCP/IP oder UDP/IP oder ein beliebiges anderes, auf Transportebene arbeitendes, Protokoll wie das Wireless Datagramm Protokoll (WDP) des Wireless Access Protokolls (WAP) implementieren. Im Fall der Unterstützung von verbindungsbasierten, auf Transportebene arbeitenden, Protokollen würden die, auf tiefer Ebene ablaufenden, Protokollstapel auch die Annahme und/oder die Herstellung der Verbindungen auf Transportebene steuern, so wie dies typischerweise von jeder Client- oder Server-Anwendung gemacht wird. Falls Sicherheit auf Transportebene erforderlich ist (wie das Secure Socket Layer (SSL) Protokoll, das Transport Layer Security (TLS) Protokoll oder das, als Teil der Wireless Access Protokoll Sammlung definierte, Wireless Transport Layer Security (WTLS) Protokoll) wird diese Sicherheitsebene ebenfalls vom, auf tiefer Ebene ablaufendem, Protokollstapel implementiert. Diese Protokolle sind nur als Beispiel aufgeführt und sollen nicht als Einschränkung der Arten von Protokollen auf Transportebene oder der Arten von Sicherheitsprotokollen auf Transportebene, auf die diese Erfindung angewendet werden kann, verstanden werden.
In der vorteilhaften Ausführungsform stellen die, auf tiefer Ebene ablaufenden, Protokollstapel LL1, LL2 eine Socket-ähnliche Anwendungsprogrammierschnittstelle (API) zur Verfügung, welche einen Deskriptor D für jede unterstützte TCP Verbindung oder gesicherte SSL/TLS/WTLS Verbindung erzeugt und zuweist. Falls ein verbindungsloses Protokoll wie UDP/IP oder WDP ohne Sicherheit auf Transportebene verwendet wird, so dient das Socketpaar (d.h. das aus IP Adresse des Initiators, Portnummer des Initiators, lokale IP Adresse sowie lokale Portnummer bestehende 4-Tupel) als Deskriptor D an dieser API. Über diese dem Subsystem MO zur Verfügung gestellte API, können TCP Segmente oder Datagramme von Initiatoren erhalten oder an Initiatoren gesendet werden. Weiterhin werden die in den, auf tiefer Ebene ablaufenden, Protokollstapeln vorhanden Ursprungsinformationen wie:

– SSL/TLS/WTLS Sitzungskennzeichner, oder
– authentifizierte Partneridentitäten wie sie in SSL/TLS/WTLS Client-Zertifikaten gefunden werden, oder
– IP Adressen und verwendete Portnummern des Initiators

Der vom, auf tiefer Ebene ablaufenden, Protokollstapel LL1 generierte und zugewiesene Deskriptor D kann auch ein den Socket-ähnlichen APIs der Subsysteme MO, AC und IA verwendet werden. In jedem der Subsysteme MO, AC und IA kann von Deskriptor D angenommen werden, daß er eine feste Beziehung zu einem gegebenen, einem spezifischen Initiator zugewiesenen, Socketpaar hat (d.h. dem aus IP Adresse des Initiators, Portnummer des Initiators, lokale IP Adresse der Gateway-Maschine sowie lokale Portnummer bestehenden 4-Tupel).
Innerhalb der Gateway-Maschine GWM können beide, auf tiefer Ebene ablaufenden, Protokollstapel LL1, LL2 die gleiche Implementation oder eine unterschiedliche Implementation zur Steuerung einer oder mehrerer Netzwerkschnittstellenkarten verwenden.
Der Fachmann wird unmittelbar erkennen, daß die von den, auf tiefer Ebene ablaufenden, Protokollstapeln LL1, LL2 notwendige Verarbeitung mittels derzeitiger Technologie bewerkstelligt werden kann. Diese wird deshalb hier nicht ausführlich beschrieben.
Nachrichtenursprungsidentifikations/Authentifizierungs-Subsystem
Das Nachrichtenursprungsidentifikations/Authentifizierungs-Subsystem MO stellt die vom Subsystem SCM zur Korrelation von Anforderungstyp- oder Antworttyp-Nachrichten zu individuellen Sitzungskontexten SC-U, SC-W, SC-Y notwendigen Informationen bzgl. des Ursprungs einer erhaltenen Nachricht (im folgendem als Ursprungsinformationen bezeichnet), basierend auf dem angenommenen oder dem verifizierten Ursprung dieser Nachricht, zur Verfügung. Das Subsystem MO interagiert über die Anwendungsprogrammierschnittstelle API1 mit dem, auf tiefer Ebene ablaufenden, Protokollstapel LL1, um TCP Segmente oder Datagramme von oder an einen entfernten, durch den Deskriptor D gekennzeichneten, Kommunikationsendpunkt zu empfangen oder zu senden und um die auf der Transportebene vorhandenen, den entfernten Kommunikationsendpunkt betreffende, Ursprungsinformationen (wie der IP-Adresse der Partners oder den SSL/TLS/WTLS Sitzungskennzeichner) abzufragen. Der vom, auf tiefer Ebene ablaufenden, Protokollstapel LL1 bereitgestellte Deskriptor D dient dem Subsystem MO als Referenz zur TCP Verbindung oder zur gesicherten SSL/TLS/WTLS Verbindung zu einem spezifischen Initiator, oder als Referenz auf den Kommunikationsendpunkt eines Partners auf dem Initiatorhost IH (falls ein verbindungsloses Protokoll ohne Sicherung auf Transportebene verwendet wird um Anforderungstyp- und Antworttyp-Nachrichten von und zu dem Initiator zu übertragen).
In einer bevorzugten Ausführungsform wird vom Subsystem MO selbst eine Socketähnliche API API2 zum Subsystem AC bereitgestellt, welche die Verwendung der gleichen Deskriptor-Werte, wie die vom, auf tiefer Ebene ablaufenden, Protokollstapel LL1 bereitgestellten, ermöglicht.
Abhängig von der erforderlichen Sicherheit (z.B. der Höhe der Integritätszusicherung und Authentifizierung) werden passende Ursprungsinformation abgefragt (entweder vom, auf tiefer Ebene ablaufenden, Protokollstapel LL1 oder vom Subsystem MO selbst mittels eines geeigneten Authentifizierungsprotokolls berechnete) welche z.B bestehen aus:

– Der IP-Adresse des externen Host in dem die Nachricht ihren Ursprung hatte (d.h. der Initiatorhost)
– Dem mit einem einzigen Datagramm assoziierten, aus IP-Adresse der Quelle, Portnummer der Quelle, IP-Adresse des Ziels und Portnummer des Ziels bestehenden, 4-Tupel (falls ein verbindungsloses Protokoll wie UDP/IP verwendet wird)
– Einem Sicherheitsassoziationskennzeichner wie der Sitzungskennzeichner der SSL, TLS oder WTLS Sitzung, welcher die Sicherheitstransformationen innerhalb der, die Anforderungstyp- oder Antworttyp-Nachricht liefernden, gesicherten Verbindung bestimmt.
– Der authentifizierten Hauptidentität (engl. Principal Identity) des Partners, welche mittels eines beliebigen verfügbaren Authentifizierungsprotokolls berechnet wurde, wie z.B. die als Teil des SSL, TLS, WTLS oder eines beliebigen anderen Protokolls implementierten Authentifizierungsprotokolle (die innerhalb des Subsystem MO implementiert sein können).
– Jedem anderen Verfahren zur Authentifizierung des Datenursprungs (optional in Verbindung mit einem Verfahren zur Sicherstellung der Datenintegrität), wie z.B. die Verwendung von Verfahren für digitale Signaturen.
– Einer beliebigen Art von Sicherheitstoken (z.B. ein vom Initiator erzeugtes und anschließend kryptographisch geschütztes Geheimnis zur Sicherstellung der Vertraulichkeit und zum Schutz gegen Wiedergabeattacken [replay attacks]), welches für eine gewisse Zeitperiode jeder aus der Initiatordomäne stammenden Anforderungstyp-Nachricht beigefügt wird. Optional kann dieses Geheimnis zwischen Anwendungen und Hosts innerhalb der Initiatordomäne ausgetauscht werden, mit der Folge, daß die innerhalb eines gegebenen Sitzungskontexts registrierten impliziten Autorisierungen für jede Anwendung oder jeden Host, der das passende Geheimnis für diesen Sitzungskontext liefern kann, gültig sind oder gültig werden. Weiterhin kann dieses Geheimnis zwischen kooperierenden Zieldomänen ausgetauscht werden; wenn eine erste Zieldomäne eine Referenz oder URI auf ein Ziel in einer zweiten, kooperierenden Zieldomäne an den Initiator (oder eine beliebige Anwendung innerhalb einer Initiatordomäne) übergibt, so wird dieser Initiator implizit für den Zugriff auf das Ziel in der zweiten Zieldomäne autorisiert. In diesem Zusammenhang impliziert die Kooperation zwischen Zieldomänen den Austausch von Sitzungskontext-spezifischen Zustandsinformationen zwischen Zieldomänen.
– einer beliebige Kombination des o.a.

Da jede der oben aufgelisteten Arten von Ursprungsinformationen, wie der Fachmann unmittelbar erkennt, mittels derzeitiger Technologie erzeugt werden kann, wird dies hier nicht detailliert beschrieben. Die von einer gegebenen Implementation unterstützten Arten von Ursprungsinformationen hängen von der erforderlichen Höhe der Sicherheit ab. Eine gegebene Implementation der hier vorgestellten Erfindung kann, geleitet durch die Erfordernisse des speziellen Anwendungsgebiets, passende Verfahren für jede der o.a. Arten von Ursprungsinformationen oder auch nur für eine Untermenge dieser bereitstellen.
MO ruft, nachdem es die erforderlichen Ursprungsinformationen abgefragt hat, das Subsystem SCM auf (wodurch die abgefragten Ursprungsinformationen und der, mit dem von LL1 erhaltenen Datenelement assoziierte, Deskriptor D zur Verfügung gestellt wird) um einen passenden Sitzungskontext SC auszuwählen (falls dieser existiert) oder einen neuen zu erzeugen. Falls eine Ausführungsform dieser Erfindung mehrere Arten von Ursprungsinformationen unterstützt, so wird eine nach der Vertrauensstufe der zugehörige Authentifizierungsmethode (Authentifizierungsstufe genannt, wobei höhere Stufen kryptographisch stärkere Überprüfungsverfahren kennzeichnen) sortierte Liste der Ursprungsinformationen erzeugt und an SCM übergeben.
5a zeigt die Verarbeitung von TCP Segmenten) oder Datagramm(en) innerhalb des Subsystems MO. Diese TCP Segmente) oder Datagramm(e) wurden über die Anwendungsprogrammierschnittstelle API1 vom, auf tiefer Ebene ablaufenden, Protokollstapel LL1 erhalten. Die Verarbeitung beginnt bei MO-10 und wird im Block MO-11 fortgesetzt, in welchem das Subsystem MO die folgenden TCP Segmente) (oder, falls ein verbindungsloses Protokoll verwendet wird, Datagramm(e)) vom, auf tiefer Ebene ablaufendem, Protokollstapel LL1 erhält. Falls durch dieses TCP Segment eine neue Verbindung aufgebaut wurde, wird der Socket-Deskriptor D für diese (falls SSL/TLS/WTLS angewendet wird, gesicherte) Verbindung abgefragt und durch das Subsystem MO verwaltet. Im Falle der Verwendung eines verbindungslosen Transportprotokolls dienen die, aus IP-Adressen und Portnummern bestehenden, Transport Adressen der beiden kommunizierenden Partner (Initiatorhost IH und Gateway-Maschine GWM) als Deskriptor D für jedes akzeptierte Datagramm eines gegebenen Initiators.
Der Kontrollfluss geht dann auf Block MO-12 über, in welchem für jede neu hergestellte TCP/IP Verbindung oder SSL/TLS/WTLS Verbindung, oder für jedes empfangene Datagramm (falls ein unsicheres, verbindungsloses Protokoll verwendet wird), jedwede verfügbare, diese Verbindung oder dieses Datagramm betreffende, Ursprungsinformationen der Transportebene vom, auf tiefer Ebene ablaufenden, Protokollstapel LL1 abgefragt wird. Eine IP Adresse, ein SSL/TLS/WTLS Sitzungskennzeichner oder eine authentifizierte Partneridentität eines SSL/TLS/WTLS Client-Zertifikats sind Beispiele solcher Ursprungsinformationen. Ein Authentifizierungsprotokoll kann optional (falls ein verbindungsorientiertes Protokoll verwendet wird) mit dem Initiator durchgeführt werden, um diesen Initiator zu authentifizieren. Zum Beispiel kann ein Herausforderungs-Mechanismus (Challenge-Mechanismus) wie das IETF PPP Authentifizierungsprotokoll (W. Simpson, PPP challenge handshake authentication protocol (CHAP), August 1996, veröffentlicht im WWW des Internets unter der Adresse www.ietf.org/rfc.html [RFC-1994]) verwendet werden. Allgemein gesagt kann in diesem Block jede, mit der akzeptierten Verbindung oder oder dem akzeptierten Datagramm in Beziehung stehende, Ursprungsinformation, die den angenommenen oder überprüften Ursprung dieser Nachricht beschreibt, abgerufen werden.
Der Kontrollfluss geht danach auf Block MO-13 über, in welchem die Folge von akzeptierten TCP Segmenten oder Datagrammen in individuelle, einzelne Protokollelemente der Anwendungsebene darstellende (d.h. Anforderungstyp-Nachrichten oder Antworttyp-Nachrichten), Datenelemente aufgeteilt wird. Falls vorhanden, basiert diese Verarbeitung auf dem im Nachrichtenkopf gefundenen Längenfeld (z.B. das message_size Feld im GIOP Kopf). Ist das Längenfeld in dem verwendeten Anwendungsprotokoll nicht vorhanden, so wird der Nachrichtenstrom analysiert und aufgrund der in dieser Analyse erkannten Struktur in seine individuellen Nachrichten syntaktisch zerlegt (engl. parsed).
Der Kontrollfluss geht danach auf Block MO-14 über, in welchem, falls der Kopf des Anwendungsebenenprotokollelements (vom Anforderungstyp) irgendeine Art von, vom Initiator erzeugtes, Sicherheitstoken enthält (kann z.B. als Servicekontext in einer GIOP Nachricht enthalten sein), so wird dieser Typ von Ursprungsinformationen der Anwendungsebene ebenfalls abgefragt. (*Hinweis: Dieser Schritt ist optional und der Kontrollfluss kann alternativ direkt von MO13 an MO-15 übergehen.)
Im Block MO-15: Einmal pro Verbindung (falls ein verbindungsorientiertes, auf Transportebene arbeitendes, Protokoll oder SSL/TLS/WTLS verwendet wird) oder für jedes akzeptierte Datagramm (falls ein verbindungsloses, auf Transportebene arbeitendes, Protokoll verwendet wird) oder immer wenn Ursprungsinformationen der Anwendungsebene im Kopf einer Anforderungstyp-Nachricht vom Initiator gefunden wurden, wird das Sitzungskontextverwalter SCM aufgerufen, um den passenden Sitzungskontext SC-W zu wählen (falls er schon existiert) oder zu erzeugen (falls er nicht existiert). Dies liefert dem Sitzungskontextverwalter SCM alle ermittelten Ursprungsinformationen (diese werden als sortierte Liste zur Verfügung gestellt, mit Elementen, die die Ursprungsinformationen enthalten, wobei die mit der höchsten Authentifizierungsstufe zuerst kommen) als auch den, vom, auf tiefer Ebene ablaufenden, Protokollstapel LL1 dieser Quelle der Nachrichten zugewiesenen, Deskriptor D, wobei letzterer als Verweis zum Sitzungskontext SC-W registriert wird.
Der Kontrollfluss geht danach auf Block MO-16 über, in welchem das vom Initiator erhaltene, eine Anforderungstyp- oder Antworttyp-Nachricht enthaltende, Datenelement mittels der Anwendungsprogrammierschnittstelle API2 zum nächsten Subsystem weitergereicht wird (d.h. zum Zugriffskontrollentscheidungs- & Erzwingungs-Subsystem AC).
5b zeigt die zur Rücksendung an den Initiator notwendige Verarbeitung innerhalb des Subsystems MO für jedes, vom Subsystem AC über die Anwendungsprogrammierschnittstelle API2 akzeptierte, Datenelement. Diese Datenelemente enthalten entweder Antworttyp-Nachrichten oder (in bestimmten Fällen) Anforderungstyp-Nachrichten.
Die Verarbeitung innerhalb des, Subsystems MO beginnt im Block MO-20 und der Kontrollfluss wird danach an Block MO-21 übergeben, in welchem ein, eine Anforderungstyp- oder Antworttyp-Nachricht enthaltendes, Datenelement vom Subsystem AC akzeptiert wird.
Danach geht der Kontrollfluss an Block MO-22 über, in welchem das akzeptierte Datenelement an den, auf tiefer Ebene ablaufenden, Protokollstapel LL1 zur Verarbeitung nach den vereinbarten und implementierten Sicherheitstransformationen (wie die durch das SSL Protokoll definierten Sicherheitstransformationen) übergeben wird, um es letztendlich, unter Berücksichtigung der vom verwendeten Deskriptor D referenzierten Zieladresse (Partner-Socket), zum externen Ziel zu liefern.
Zugriffskontrollentscheidungs- & Erzwingungs-Subsystem
Das Zugriffskontrollentscheidungs- & Erzwingungs-Subsystem (in 4a als Subsystem AC dargestellt) erhält über die Socket-ähnliche Anwendungsprogrammierschnittstelle API2 individuelle Datenelemente vom Subsystem MO, wobei jedes dieser Datenelemente entweder eine Anforderungstyp- oder Antworttyp-Nachricht enthält. Diese, über Anwendungsprogrammierschnittstelle API2 vom Subsystem MO akzeptierten oder an Subsystem MO zurückgesendeten, Datenelemente sind auf irgendeine Art und Weise mit dem Deskriptor D assoziiert, welcher ursprünglich von LL1 den Segmenten) oder Datagramm(en) zugewiesen wurde, die ursprünglich das Datenelement enthielten.
Subsystem AC filtert und verarbeitet den über Anwendungsprogrammierschnittstelle API2 akzeptierten Nachrichtenstrom indem es einfach alle Antworttyp-Nachrichten enthaltenden Datenelemente ohne weitere Verarbeitung oder Änderung über die Anwendungsprogrammierschnittstelle API3 an das nächste Subsystem IA weiterreicht, während alle Anforderungstyp-Nachrichten enthaltenden Datenelemente einem Zugriffskontrollentscheidungsprozess unterzogen werden, der entweder in einem Überspringen der Datenelemente mit oder ohne einer Ausnahmeantwortnachricht, falls der Zugriff verweigert wurde, oder der Weiterleitung der Datenelemente über die Anwendungsprogrammierschnittstelle API3 an das Subsystem IA, falls der Zugriff gewährt wurde, resultiert. In der Richtung vom Zielhost TH zum Initiatorhost IH werden alle über die Anwendungsprogrammierschnittstelle API3 vom Subsystem IA akzeptierten Datenelemente einfach ohne weitere Verarbeitung über die Anwendungsprogrammierschnittstelle API2 an das Subsystem MO weitergereicht. Während der Weiterreichung eines gegebene Datenelements in beliebiger Richtung durch Subsystem AC wird in beiden Anwendungsprogrammierschnittstellen API2, API3 der selbe Deskriptor D verwendet. In beiden Richtungen dient dieser Deskriptor D zur Assoziation der Anforderungstyp- oder Antworttyp-enthaltenden Datenelemente mit der passenden Verbindung zum entfernten Kommunikationsendpunkt (d.h. der Initiatorhost IH) als auch des passenden Sitzungskontextes (wie ursprünglich vom Sitzungskontextverwaltungs-Subsystem SCM gewählt).
In 6a und 6b wird die innerhalb des Subsystems AC durchgeführte Verarbeitung detailliert beschrieben. 6a und 6a und die folgende Beschreibung verwenden für Elemente, die auch in 4a verwendet werden, die selben Bezeichnungen.
Wie in 6a dargestellt wird, beginnt die Verarbeitung des Zugriffskontrollentscheidungs- & Erzwingungs-Subsystem AC im Block AC-10 und wird dann in Block AC-11 fortgeführt, in welchem das nächste, mit dem Deskriptor D assoziierte, Datenelement vom Nachrichtenursprungsidentifikations/Authentifizierungs-Sub system MO über eine Anwendungsprogrammierschnittstelle API2 akzeptiert wird, wobei dieses Datenelement entweder eine Anforderungstyp-Nachricht oder eine Antworttyp-Nachricht enthält.
Der Kontrollfluss geht dann auf Block AC-12 über, in welchem der, im akzeptierten Datenelement übergebene, Nachrichtenkopf auf das Vorhandensein einer Anforderungstyp-Nachricht überprüft wird. In Block AC-13 wird dann das Ergebnis der Überprüfung aus Block AC-12 festgestellt. Ist die Nachricht keine Anforderungstyp-Nachricht, so wird der Kontrollfluss an Block AC-19 übergeben, in welchem das Datenelement einfach an das nächste Subsystem IA weitergereicht wird.
Falls die Nachricht eine Anforderungstyp-Nachricht ist wird der Kontrollfluss an Block AC-14 übergeben, in welchem der das Ziel der Anforderungstyp-Nachricht bestimmende Objektschlüssel, die Objektreferenz oder die URI aus dem Nachrichtenkopf oder Nachrichtenkorpus des Datenelements abgefragt wird. Im Block AC-15 wird danach ein Regelwerk von Zugriffskontrollrichtlinien konsultiert, um festzustellen ob die Anfrage an das Ziel, dessen Referenz in Block AC-14 ermittelt wurde, erlaubt ist. Der Zugriff auf gewisse Ziele kann zum Bootstrapping oder für andere Zwecke auch ohne vorherige implizite Autorisierung ermöglicht werden. Solche Ziele können in einer solchen Zugriffskontrollrichtline entweder als erlaubte Ziele (d.h. explizit authorisiert) definiert werden oder sie würden während der Initialisierung eines neuen Sitzungskontexts automatisch registriert werden.
Der Kontrollfluss geht dann auch Block AC-16 über, in welchem das Ergebnis der Überprüfung aus Block AC-15 ermittelt wird. Ist der Zugriff auf das Ziel explizit autorisiert (d.h. der Zugriff wurde aufgrund des Regelwerks von Zugriffskontrollrichtlinien gestattet) wird der Kontrollfluss an Block AC-19 übergeben.
Ist die Anforderung an das Ziel nicht explizit autorisiert (aufgrund des Regelwerks von Zugriffskontrollrichtlinien), so geht der Kontrollfluss auf Block AC-17 über, in welchem das Subsystem innerhalb des Sitzungskontextverwaltungs-Subsystems SCM mit einer „ÜBERPRÜFE-KONTEXT" Anforderung REQ2 aufgerufen wird, um das durch den, vom Subsystem AC; im Block AC14 für den Objektschlüssel, die Referenz oder die URI ermittelten, Deskriptor D referenzierte, Sitzungskontextdatenelement SC-U, SC-W, SC-Y zu suchen. Das Ergebnis dieser Suche wird vom Sitzungskontextverwalter SCM zurückgegeben.
In Block AC-18 wird dann das Ergebnis des Aufrufs des Sitzungskontextverwalters SCM ermittelt. Ist laut Sitzungskontextverwalter SCM der Schlüssel, die Referenz oder die URI gefunden worden, wird der Kontrollfluss an Block AC-19 zurückgegeben (falls der Schlüssel, die Referenz oder die URI in dem gegebenen Sitzungskontext gefunden wurde, wird angenommen, daß der Zugriff auf das von dem Schlüssel, der Referenz oder der URI referenzierte Ziel implizit autorisiert ist und der Zugriff durch das Subsystem AC gewährt werden soll).
Wird vom Sitzungskontextverwalter SCM angezeigt, daß der Schlüssel, die Referenz oder die URI nicht gefunden wurde, wird der Kontrollfluss an Block AC-20 übergeben welcher das, die Anforderungstyp-Nachricht enthaltende, Datenelement einfach ohne es an das nächste Subsystem zu übergeben, verwirft. Der Kontrollfluss geht dann entweder auf Block AC-21 über (dies ist ein optionaler Schritt), in welchem eine, daß außerordentliche Ereignis der Zugriffsverweigerung anzeigende, Antworttyp-Nachricht erzeugt wird und das Subsystem darauf terminiert, oder das Subsystem terminiert direkt nach der Beerdigung von Block AC-20 ohne den Kontrollfluss an Block AC-21 zu übergeben.
6b zeigt die Verarbeitung von den Datenelementen, die vom Subsystem AC über die Anwendungsprogrammierschnittstelle API3 vom Subsystem IA akzeptiert wurden. Die Verarbeitung beginnt im Block AC-30 und wird danach im Block AC-31 fortgeführt, in welchem das nächste, in irgendeiner Art und Weise mit Deskriptor D assoziierte und entweder eine Anforderungstyp-Nachricht oder Antworttyp-Nachricht enthaltende, Datenelement über die Anwendungsprogrammierschnittstelle API3 akzeptiert wird. Der Verarbeitung wird dann in Block AC-32 fortgeführt, in welchem das gleiche Datenelement (ohne jede weitere Verarbeitung) an das Subsystem MO übergeben wird (unter Verwendung der Anwendungsprogrammierschnittstelle API2)
Subsystem für implizite Autorisierung
Das Subsystem für implizite Autorisierung IA aus 4a erhält vom Subsystem AC über die Socket-ähnliche Anwendungsprogrammierschnittstelle API3 aus 4a individuelle Datenelemente, die mit einem gegebenen Deskriptor D assoziiert sind, wobei jedes Datenelement entweder eine Anforderungstyp-Nachricht oder eine Antworttyp-Nachricht enthält, und leitet diese abgefragten Datenelemente ohne jede weitere Verarbeitung über eine weitere Anwendungsprogrammierschnittstelle Anwendungsprogrammierschnittstelle API4 an den Proxy-Server PS (oder in einer alternativen Ausführungsform direkt an die Anwendung APP) weiter.
Über Anwendungsprogrammierschnittstelle API4 akzeptierte Datenelemente, die vom Subsystem PS (oder in einer alternative Ausführungsform direkt von der Anwendung APP) gesendet wurden, werden von Subsystem IA verarbeitet, um Ereignisse der impliziten Autorisierung zu erkennen, d.h. erkennen jeglicher Objektreferenzen oder URIs, die als Parameter oder innerhalb Nachrichtenkörpers des, über die Anwendungsprogrammierschnittstelle Anwendungsprogrammierschnittstelle API4 akzeptierten, Datenelements enthalten sind. Anschließend wird das, eine Anforderungstyp-Nachricht oder Antworttyp-Nachricht enthaltende, Datenelement über die Anwendungsprogrammierschnittstelle API3 an Subsystem AC weitergereicht. Während der Weiterleitung in beliebiger Richtung eines gegebenen Datenelements über Subsystem IA wird in beiden Anwendungsprogrammierschnittstellen API3, API4 derselbe Deskriptor D verwendet.
Im folgendem wird unter Bezug auf 7a und 7b eine detaillierte Beschreibung der innerhalb von Subsystem IA stattfindenden Verarbeitung gegeben. Elemente die ebenfalls in 4a gezeigt werden haben die selben Bezeichner.
7a zeigt die Verarbeitung der vom Subsystem IA über die Anwendungsprogrammierschnittstelle API3 vom Subsystem AC erhaltenen und über die Anwendungsprogrammierschnittstelle API4 zum Proxy-Server PS (oder, in der alternativen Ausführungsform als Interzeptor auf Anwendungsebene ALI, direkt zur Anwendung APP) weitergereichten Datenelemente. Die Verarbeitung startet im Block IA-10 und wird im Block IA-11 fortgeführt, in welchem das nächste, in irgendeiner Art und Weise mit dem Deskriptor D assoziierte und entweder eine Anforderungstyp-Nachricht oder Antworttyp-Nachricht enthaltende, Datenelement über die Anwendungsprogrammierschnittstelle API3 vom Subsystem AC erhalten wird. Die Verarbeitung wird danach in Block IA-12 fortgeführt, wo das gleiche, wiederum mit dem gleichem Deskriptor D assoziierte, Datenelement (ohne jede weitere Verarbeitung) über die Anwendungsprogrammierschnittstelle API4 zum Subsystem PS (oder zur Anwendung APP) weitergeleitet wird.
7b zeigt die Verarbeitung von, über die Anwendungsprogrammierschnittstelle API4 akzeptierten und vom Subsystem PS stammenden (oder, in der alternativen Ausführungsform als Interzeptor auf Anwendungsebene, direkt von der Anwendung APP stammenden), Datenelementen zur Weiterleitung (nach der Verarbeitung) zum Subsystem AC.
Die Verarbeitung beginnt in Block IA-20 und wird im Block IA-21 fortgeführt, in welchem das nächste vom Subsystem PS oder der Anwendung APP stammende, in irgendeiner Art und Weise mit Deskriptor D assoziierte und entweder eine Anforderungstyp-Nachricht oder Antworttyp-Nachricht enthaltende, Datenelement über die Anwendungsprogrammierschnittstelle API4 akzeptiert wird. Der Kontrollfluss geht dann auf Block IA-22 über, in welchem der Nachrichtenkörper oder die Parameter der im akzeptierten Datenelement enthaltenen Anforderungstyp-Nachricht oder Antworttyp-Nachricht auf das Vorhandensein jedweder mit dieser Nachricht übergebenen Objektreferenzen oder URIs durchsucht oder analysiert (gescannt oder geparsed) werden.
Der Kontrollfluss geht dann auf Block IA-23 über, in welchem das Ergebnis der o.a. Durchsuchung ermittelt wird. Wurde keine Objektreferenz oder URI gefunden, wird Block IA-25 aufgerufen, in welchem das, die Anforderungstyp-Nachricht oder Antworttyp-Nachricht enthaltende, Datenelement zum Subsystem AC weitergereicht wird, wodurch die Anwendungsprogrammierschnittstelle API3 und der gleiche Deskriptor D, welcher mit dem Datenelement, als es über die Anwendungsprogrammierschnittstelle API4 akzeptiert wurde, assoziiert wurde, verwendet wird.
Wurden bei der Durchsuchung eine Objektreferenz oder URI oder eine Vielzahl von Objektreferenzen oder URIs gefunden, wird der Kontrollfluss an Block IA-24 übergeben, in welchem das Subsystem im Sitzungskontextverwaltungs-Subsystem SCM mit einer „MODIFIZIERE-KONTEXT" Anforderung REQ3 aufgerufen wird, in der das Sitzungskontextverwaltungs-Subsystem SCM aufgefordert wird, die gefundene(n) Objektreferenzen) oder URI(s) mit dem, vom Subsystem AC bereitgestellten Deskriptor D referenzierten, Sitzungskontextdatenelement zu registrieren.
Der Kontrollfluss geht dann auf Block IA-25 über, in welchem das, die Anforderungstyp- oder Antworttyp-Nachricht enthaltende, Datenelement zum Subsystem AC weitergeleitet wird. Daraufhin terminiert dieses Verfahren.
Sitzungskontextverwaltungs-Subsystem
Das Sitzungskontextverwaltungs-Subsystem SCM der 4a verwaltet den Zustand aller (potentiell gleichzeitig existierender) Eingangssitzungen als eine variable Anzahl von Sitzungskontextdatenelementen, verwaltet die Erzeugung oder Löschung eines jeden Sitzungskontextdatenelements, bedient Anforderungen vom Subsystem MO zur Auswahl eines, zu einer gegebenen Verbindung oder eines gegebenen Socket-Paars (falls ein verbindungsloses Protokoll auf Transportebene verwendet wird), passenden Sitzungskontextdatenelements SC-U, SC-W, SC-Y, bedient Anforderungen des Subsystems AC auf Überprüfung eines gegebenen Sitzungskontextdatenelements SC-U, SC-W, SC-Y auf Existenz einer impliziten Autorisierung zum Zugriff auf gewisse Ziele Target1, Target2 und bedient Anforderungen des Subsystems IA zur Änderung eines gegebenen Sitzungskontextdatenelements SC-U, SC-W, SC-Y zur Registrierung einer neu gefundenen Objektreferenz oder URI.
8 zeigt die allgemeine Struktur eines Sitzungskontextdatenelements SC-U, SC-W, SC-Y, welches die Verwaltung des vollständigen Sitzungskontexts einer einzelnen Eingangssitzung ermöglicht.
Bezug nehmend auf 8: Das DESKRIPTOR ATTRIBUT SC1 enthält den (möglicherweise mehrfach geänderten) vom Subsystem MO zur Registrierung als Verweis zum Sitzungskontextdatenelement SC-U, SC-W, SC-Y bereitgestellten Deskriptor D. Der Deskriptor dient als einfaches Mittel zur Assoziation der von den Subsystemen MO, AC, IA verarbeiteten Anforderungstyp-Nachrichtendatenelemente oder Antworttyp-Nachrichtendatenelemente mit einem gegebenen Sitzungskontext. Diese Assoziation kann auch durch andere Verfahren erreicht werden (wie z.B. die Übergabe eines Verweises, der den ausgewählten Sitzungskontext mit jedem, vom den Subsystemen MO, AC, IA verarbeiteten, Nachrichtendatenelement referenziert). Der im DESKRIPTOR ATTRIBUT SC1 enthaltene Wert kann sich innerhalb der Lebensdauer des Sitzungskontexts ändern: Das DESKRIPTOR ATTRIBUT wird gelöscht, falls der in ihm enthaltene Deskriptor D abgemeldet wird und er wird gesetzt, falls einer neuer Deskriptor D2 für diesen Sitzungskontext registriert wird.
In einer alternativen Ausführungsform, in dem das Subsystem MO auf n Hosts repliziert wurde, kann das DESKRIPTOR ATTRIBUT SC1 tatsächlich eine Menge von Deskriptoren D (D1 bis Dn) enthalten, wobei jede individuelle Instanz des Subsystems MO seinen eigenen individuellen Deskriptor hat.
Das SITZUNGS URSPRUNGS ATTRIBUT SCA2 wird während der Erzeugung des Sitzungskontextdatenelements initialisiert und während der Lebensdauer der zugehörigen Eingangssitzung nicht verändert. Das SITZUNGS URSPRUNGS ATTRIBUT SCA2 bestimmt die notwendigem Ursprungsinformationen (ORI), die von einem beliebigen Verfahren mit einer vom einem Initiator empfangenen Nachricht assoziiert sein müssen, um es zu ermöglichen, diese Nachricht diesem spezifischem Sitzungskontextdatenelement zuzuweisen.
Das (optionale) Attribut „LISTE DER AKTUELLEN ORI DATENELEMENTE" SCA3 enthält eine Liste von, vom Subsystem MO durch die allerletzte „SELEKTIERE KONTEXT" Anforderung bereitgestellte, Ursprungsinformationen (ORI). Der in diesem Attribut enthaltene Wert kann sich während der Lebensdauer eines gegebenen Sitzungskontextdatenelements ändern: Das Attribut wird immer dann gelöscht wenn SCA1 innerhalb desselben Sitzungskontextdatenelements gelöscht wird und es wird bei der Registrierung eines neuen Deskriptors D initialisiert (d.h. wenn SCA1 initialisiert wird). Dieses Attribut (falls implementiert) dient während einer Zugriffskontrollentscheidung (falls eine implizite Autorisierung im aktuellen Sitzungskontextdatenelement nicht gefunden wird) als Referenz zu weiteren Sitzungskontextdatenelementen, die eventuell eine für die Zugriffserlaubnis erforderliche implizite Autorisierung enthalten. Diese weiteren referenzierten Sitzungskontextdatenelemente sind die, bei denen das SITZUNGS URSPRUNGS ATTRIBUT mit irgendeinem der, in diesem Sitzungskontextdatenelement gespeicherten, ORI DATENELEMENTE aus der LISTE DER AKTUELLEN ORI DATENELEMENTE übereinstimmt.
Es ist besonders wichtig, das jedes Sitzungskontextdatenelement ein Attribut „LISTE DER IMPLIZIT AUTORISIERTEN OBJEKTREFERENZEN / URIS" SCA4 enthält. Dieses Attribut enthält eine Liste von Objektreferenzen oder URIs, für die der Sitzungspartner (identifiziert durch SCA2) implizit zum Zugriff innerhalb des Kontextes der, durch dieses Sitzungskontextdatenelement repräsentierten, Eingangssitzung autorisiert wurde.
Das LEERLAUFZEITATTRIBUT SCA5 eines gegebenen Sitzungskontextdatenelements SC-U, SC-W, SC-Y kann bei jeder Zuweisung einer Nachricht zu diesem Sitzungskontext und Verarbeitung durch irgendeines der Subsysteme MO, AC oder IA zurückgesetzt werden. Die zur Zurücksetzung dieses Attributs notwendigen Interaktionen sind offensichtlich und werden in keiner der hier dargestellten Abbildungen gezeigt. Der Ablauf des zu dem LEERLAUFZEITATTRIBUT SCA5 eines Sitzungskontextdatenelements gehörenden Leerlaufzeitintervalls kann zur Terminierung der zugehörigen Eingangssitzung und zur Freigabe jedweder verwendeter Ressourcen des zugehörigen Sitzungskontextdatenelements dienen.
Einzelne Sitzungskontextdatenelemente und deren Attribute können durch hier nicht weiter ausgeführte einfache Verwaltungsverfahren gelesen, modifiziert oder gelöscht werden. Es ist Erwähnenswert, daß die Löschung (mittels eines Verwaltungsverfahrens) eines bestimmten Elements der, innerhalb des Attributs SCA4 eines bestimmten Sitzungskontextdatenelement SC-W enthaltenen, Liste von Objektreferenzen oder URIs den selektiven Widerruf jeder, vorher innerhalb der zugehörigen Eingangssitzung W erteilten, impliziten Autorisierung erlaubt.
Unter Bezugnahme auf 9 wird nun die Verarbeitung der „SELEKTIERE KONTEXT" Anforderung innerhalb des Sitzungskontextverwalters SCM beschrieben. Die Verarbeitung beginnt im Block SCM-10 und wird im Block SCM-11 fortgeführt, in welchem eine gegebene „SELEKTIERE KONTEXT" Anforderung vom Subsystem MO akzeptiert wird, die zur Selektion oder Erzeugung eines passenden Sitzungskontextdatenelements SC-U, SC-W, SC-Y auffordert. Zusammen mit dieser Anforderung stellt das Subsystem MO eine, Datenelemente und einen Deskriptor D enthaltende, Liste von Ursprungsinformationen (ORI) zur Verfügung.
Der Kontrollfluss geht dann auf Block SCM-12 über, in welchem jede vorherige Verwendung des Wertes des Deskriptor D in jedem der, vom Sitzungskontextverwalters SCM verwalteten, Sitzungskontextdatenelemente abgemeldet wird. Durch die Überprüfung aller, vom Sitzungskontextverwalter SCM verwalteten, Sitzungskontextdatenelemente, um zu Ermitteln ob der Wert des Deskriptors D schon innerhalb des Deskriptorattributs gespeichert wurde und falls er in einem beliebigen Sitzungskontextdatenelement gefunden wurde, durch einfache Löschung des Deskriptorattributs innerhalb dieses Sitzungskontextdatenelements, wird die Abmeldung erreicht. In dem optionalen Fall, daß dieses Sitzungskontextdatenelement ein „Liste der aktuellen ORI Datenelemente"-Attribut enthält, wird dieses Attribut ebenfalls gelöscht. Falls eine Wiederverwendung von Deskriptorwerten durch die, von dem, auf tiefer Ebene ablaufenden und diese Deskriptoren erzeugenden, Protokollstapel LL1, verwendeten Algorithmen nicht ausgeschlossen werden kann, ist eine Abmeldung nötig.
Der Kontrollfluss geht dann auf Block SCM-13 über, in welchem aus der, vom Subsystem MO gelieferten, Liste von Urspungsinformations (ORI)-Datenelementen das erste Datenelement DI1 (welches das ORI Datenelement mit der höchsten Authentifizierungsstufe ist) ausgewählt wird und die vollständige Menge der, vom Sitzungskontextverwalter SCM verwalteten, Sitzungskontextdatenelemente auf das Vorhandensein eines übereinstimmenden Sitzungsursprungsattributwerts durchsucht wird.
Der Kontrollfluss geht dann auf den Block SCM-14 über, in welchem das Ergebnis dieser Suche ermittelt wird. Falls eine Übereinstimmung zwischen dem, aus der, vom Subsystem MO gelieferten, Liste von Urspungsinformations (ORI)-Datenelementen ausgewählten, Datenelement DI1 und einem der, vom Sitzungskontextverwalter SCM verwalteten, Datenelemente vorhanden ist (dieses Sitzungskontextdatenelement wird im folgendem als Sitzungskontextdatenelement SC-W bezeichnet), geht der Kontrollfluss direkt an Block SCM-18 über.
Fall kein übereinstimmender Sitzungskontextattributwert in irgendeinem der, vom Sitzungskontextverwalter SCM verwalteten, Sitzungskontextdatenelemente gefunden wird geht der Kontrollfluss auf Block SCM-15 über, in welchem ein neues Sitzungskontextdatenelement erzeugt wird (dieses Sitzungskontextdatenelement wird im folgendem als Sitzungskontextdatenelement SC-W bezeichnet) und danach auf Block SCM-16 über, in welchem SC-W initialisiert wird. Diese Initialisierung kann die Initialisierung des, in 8 als Sitzungskontextattribut SCA5 dargestellten, Leerlaufzeitattributs oder die Initialisierung des „Liste der implizit autorisierten Objektreferenzen/URIs"-Attributs (in 8 als SCA4 dargestellt) mit einer Initialmenge von Objektreferenzen oder URIs, auf die am Anfang zum Bootstrapping zugegriffen werden muss, enthalten. Nach der Beendigung der im Block SCM-16 ausgeführten Initialisierungsverfahren geht der Kontrollfluss auf Block SCM-17 über, in welchem das, aus der, vom Subsystem MO gelieferten, Liste von Urspungsinformations- (ORI)-Datenelementen ausgewählte, Ursprungsinformations(ORI) Datenelement DI1 (das ORI Datenelement mit der höchsten Authentifizierungsstufe) innerhalb des Sitzungsursprungsattributs (in 8 als Sitzungskontextattribut SCA2 dargestellt) des neu erzeugten Sitzungskontextdatenelements SC-W registriert wird.
Der Kontrollfluss geht dann auf Block SCM-18 über, in welchem der, vom Subsystem MO mittels der „SELEKTIERE KONTEXT" Anforderung bereitgestellte, Deskriptor D als der neue Verweis zum ausgewählten oder neu erzeugten Sitzungskontextdatenelement SC-W registriert wird. D wird durch Speicherung innerhalb des Deskriptorattributs (in 8 als Sitzungskontextattribut SCA1 dargestellt) des ausgewählten oder neu erzeugten Sitzungskontextdatenelements SC-W registriert. Der Kontrollfluss geht dann auf Block SCM-19 über, in welchem die, vom Subsystem MO mittels der „SELEKTIERE KONTEXT" Anforderung bereitgestellte, Liste von Ursprungsinformationen (ORI) enthaltenen Datenelemente innerhalb der „LISTE DER AKTUELLEN ORI DATENELEMENTE" (in 8 als Sitzungskontextattribut SCA3 dargestellt) des ausgewählten oder neu erzeugten Sitzungskontextdatenelements SC-W gespeichert wird. Dieses Verfahren terminiert in Block SCM-21.
Unter Bezugnahme auf 10 wird nun die Verarbeitung der „ÜBERPRÜFE KONTEXT" Anforderung innerhalb des Sitzungskontextverwalters SCM beschrieben.
Die Verarbeitung; beginnt im Block SCM-30 und wird im Block SCM-31 fortgeführt, in welchem eine gegebene „ÜBERPRÜFE KONTEXT" Anforderung des Subsystems AC akzeptiert wird, welche die Überprüfung veranlasst, ob der/die vom Subsystem AC mit dieser Anforderung bereitgestellte Objektschlüssel, Objektreferenz oder URI innerhalb des „LISTE DER IMPLIZIT AUTORISIERTEN OBJEKTREFERENZEN / URIS"-Attributs des, dem vom Subsystem AC mit dieser Anforderung bereitgestellten Deskriptor D entsprechenden, Sitzungskontextdatenelement SC-W gespeichert ist.
Der Kontrollfluss geht dann auf Block SCM-32 über, in welchem das passende Sitzungskontextdatenelement SC-U, SC-W, SC-Y selektiert wird, dessen „DESKRIPTOR ATTRIBUT"-Wert mit dem, vom Subsystem AC mittels der „ÜBERPRÜFE KONTEXT" Anforderung bereitgestellten, Deskriptor D übereinstimmt. Das ausgewählte Sitzungskontextdatenelement wird im folgendem als Sitzungskontext SC-W bezeichnet.
Der Kontrollfluss geht dann auf Block SCM-33 über, in welchem das „Liste der implizit autorisierten Objektreferenzen / URIs"-Attribut (in 8 als Sitzungskontextattribut SCA4 dargestellt) des Sitzungskontextdatenelements SC-W nach einem Wert, der mit dem bzw. der, vom Subsystem AC mit dieser „ÜBERPRÜFE-KONTEXT" Anforderung zur Verfügung gestelltem bzw. gestellten, Objektschlüssel, Objektreferenz oder URI übereinstimmt, durchsucht wird.
Der Kontrollfluss geht dann auf Block SCM-34 über, in welchem das Ergebnis dieser Suche ermittelt wird. Falls ein Listenelement, welches mit dem bzw. der, vom Subsystem AC zur Verfügung gestellten bzw. gestelltem, Objektschlüssel, Objektreferenz oder URI übereinstimmt, innerhalb des „Liste der implizit autorisierten Objektreferenzen / URIs"-Attributs gefunden wurde, wird der Kontrollfluss an Block SCM-35 übergeben, in welchem ein „WURDE GEFUNDEN" an das Subsystem AC zurückgegeben und das Verfahren terminiert wird. Andernfalls wird der Kontrollfluss an Block SCM-36 übergeben, in welchem ein „NICHT GEFUNDEN" an das Subsystem AC zurückgeben und das Verfahren terminiert wird.
Unter Bezugnahme auf 11 wird nun eine optionale, erweiterte Verarbeitung der „ÜBERPRÜFE KONTEXT" Anforderung gezeigt. Die Erweiterung beschreibt eine erweiterte Suche nach dem bzw. der, vom Subsystem AC mit dieser „ÜBERPRÜFE KONTEXT" Anforderung zur Verfügung gestellten bzw. gestelltem, Objektschlüssel, Objektreferenz oder URI falls in dem, vom Subsystem AC mit dieser Anforderung bereitgestellten, dem Deskriptor D entsprechendem, Sitzungskontextdatenelement kein übereinstimmender Wert gefunden wird. Die in 12 detailliert dargestellte erweiterte Verarbeitung führt die Suche in weiteren, vom Sitzungskontextverwalter SCM bereitgestellten, Sitzungskontextdatenelementen durch, welche mit Hilfe des „Liste der aktuellen ORI Datenelemente"-Attributs (in 8 als Sitzungskontextattribut SCA3 dargestellt) ausgewählt werden.
11 und die folgende Beschreibung verwenden für Elemente, die auch in 10 verwendet werden, die selben Bezeichnungen. Die in 11 dargestellte Verarbeitung im Block SCM-30 bis SCM-35 entspricht der obigen Beschreibung dieser Blöcke unter Verwendung der 10. Die folgende Beschreibung konzentriert sich auf die Blöcke, die spezifisch für die erweiterte Verarbeitung sind.
Der Kontrollfluss geht von Block SCM-33 auf den Entscheidungsblock SCM-34 über, welcher das Ergebnis der Suche ermittelt. Falls ein Listenelement, welches mit dem bzw. der, vom Subsystem AC zur Verfügung gestellten bzw. gestelltem, Objektschlüssel, Objektreferenz oder URI übereinstimmt innerhalb des „Liste der implizit autorisierten Objektreferenzen / URIs"-Attributs gefunden wurde, wird der Kontrollfluss an Block SCM-35 übergeben, dessen Verarbeitung wie bereits oben beschrieben verläuft.
Andernfalls, falls kein solches übereinstimmendes Listenelement in dem „Liste der implizit autorisierten Objektreferenzen / URIs"-Attribut des Sitzungskontextdatenelements SC-W gefunden wurde, geht der Kontrollfluss auf Block SCM-37 über, in welchem die erweiterte Suche nach dem bzw. der, vom Subsystem AC bereitgestelltem bzw. bereitgestellten, Objektschlüssel, Objektreferenz oder URI gestartet wird. Dieser Block SC-37 wird im folgendem in 12 detaillierter beschrieben.
Nun Bezug nehmend auf 12: Die Verarbeitung der erweiterten Suche beginnt im Block SCM-40 und wird im Block SCM-41 fortgeführt, in welchem das erste Listenelement der, im „Liste der aktuellen ORI Datenelemente"-Attribut (in 8 als Sitzungskontextattribut SCA3 dargestellt) des Sitzungskontextdatenelements SC-W enthaltenen, Liste ausgewählt. Dieses Element ist ein Ursprungsinformationen- (ORI) Datenelement, welches einige zusätzliche Ursprungsinformationen bzgl. des Initiators beschreibt, welcher die aktuelle Anforderungstyp-Nachricht, für die der Zugriff gestattet oder zurückgewiesen werden soll, gesendet hat.
Der Kontrollfluss geht dann auf Block SCM-42 über, in welchem die vollständige Menge der, vom Sitzungskontextverwalter SCM verwalteten, Sitzungskontextdatenelemente nach einem Sitzungskontextattributwert (in 8 als Sitzungskontextattribut SCA2 dargestellt) der mit dem im Block SCM-41 ausgewählten Ursprungsinformations- (ORI) Datenelement übereinstimmt, durchsucht wird.
Der Kontrollfluss geht dann auf Entscheidungsblock SCM-43 über, in welchem das Ergebnis dieser Suche festgestellt wird. Falls in keinem Sitzungsursprungsattribut aller, vom Sitzungskontextverwalter SCM verwalteten, Sitzungskontextdatenelemente ein solcher übereinstimmender Wert gefunden wurde, geht der Kontrollfluss direkt auf Block SCM-47 über, in welchem die, in dem „Liste der aktuellen ORI Datenelemente"-Attribut (in 8 als Sitzungskontextattribut SCA3 dargestellt) des Sitzungskontextdatenelements SC-W enthaltene, Liste nach weiteren noch vorhandenen Listenelementen überprüft wird.
Der Kontrollfluss geht dann auf einen weiteren Entscheidungsblock SCM-48 über, in welchem das Ergebnis des Blocks SCM-47 ermittelt wird. Sind weitere Datenelemente in der Liste enthalten, so geht der Kontrollfluss auf Block SCM-41 über, in welchem bisher noch nicht überprüfte Ursprungsinformations- (ORI) Datenelemente des „Liste der aktuellen ORI Datenelemente"-Attributs (in 8 als Sitzungskontextattribut SCA3 dargestellt) wie oben beschrieben verarbeitet werden. Wurden durch die Überprüfung im Block SCM-47 keine weiteren Datenelemente gefunden, so geht der Kontrollfluss auf Block SCM-49 über, in welchem ein „NICHT GEFUNDEN" an das Subsystem AC zurückgegeben und die Verarbeitung terminiert wird.
Falls im Entscheidungsblock SCM-43 feststellt wird, daß die im Block SCM-42 durchgeführte Suche einen übereinstimmenden Wert in einem Sitzungsursprungsattribut eines Sitzungskontextdatenelements SC-Y gefunden hat, geht der Kontrollfluss auf Block SCM-44 über, in welchem das „Liste der implizit autorisierten Objektreferenzen / URIs"-Attribut dieses Sitzungskontextdatenelements SC-Y nach dem bzw. der, vom Subsystem AC bereitgestelltem bzw. bereitgestellten, Objektschlüssel, Objektreferenz oder URI durchsucht wird.
Der Kontrollfluss geht dann auf einen weiteren Entscheidungsblock SCM-45 über, in welchem das Ergebnis dieser Suche ermittelt wird. Falls ein mit dem bzw. der, vom Subsystem AC bereitgestelltem bzw. bereitgestellten, Objektschlüssel, Objektreferenz oder URI übereinstimmendes Listenelement in dem „Liste der implizit autorisierten Objektreferenzen / URIs"-Attribut von SC-Y gefunden wird, so geht der Kontrollfluss auf Block SCM-46 über, in welchem ein „WURDE GEFUNDEN" an Subsystem AC zurückgegeben und das Verfahren terminiert wird. Andernfalls geht der Kontrollfluss auf Block SCM-47 über, in welchem die im „Liste der aktuellen ORI Datenelemente"-Attribut (in 8 als Sitzungskontextattribut SCA3 dargestellt) enthaltene Liste des Sitzungskontextdatenelements SC-W wie bereits oben beschrieben auf das Vorhandensein weiterer Listenelemente überprüft wird.
In einer weiteren vorteilhaften Ausführungsform der hier beschriebenen Erfindung ist auch das folgende Szenario möglich: Ein Sitzungskontext in einem kooperierenden Sitzungskontextverwaltungssubsystem eines weiteren Interzeptors auf Anwendungsebene oder Gateways auf Anwendungsebene kann selektiv (z.B. in Abhängigkeit vom Objekttyp) konsultiert werden. Dies erfordert Sitzungskontextverwaltungssubsystem zu Sitzungskontextverwaltungssubsystem-Interaktionen die auf einem CORBA-ähnlichen Interaktionsmechanismus basieren (z.B. CORBA, DCOM, Java RMI, SOAP). Sitzungskontextverwaltungssubsysteme können das Wissen über solche kooperierenden Sitzungskontextverwaltungssubsysteme verwalten. In diesem Fall müsste der passende Sitzungskontext in diesem Sitzungskontextverwaltungssubsystem basierend auf den, vom ersten Sitzungskontextverwaltungssubsystem bereitgestellten, ORI durch das kooperierende Sitzungskontextverwaltungssubsystem ausgewählt werden. Falls dieser Sitzungskontext innerhalb des kooperierenden Sitzungskontextverwaltungssubsystems einen Eintrag für eine implizite Autorisierung für Objektreferenz, Objektschlüssel oder URI enthält, welche das zur Entscheidung anstehende Ziel der Anforderung angibt, so wird er Zugriff gestattet.
Nun wird, Bezug nehmend auf 13, die Verarbeitung der „MODIFIZIERE KONTEXT" Anforderung innerhalb des Sitzungskontextverwalters SCM beschrieben: Die Verarbeitung beginnt im Block SCM-50 und wird danach in Block SCM-51 fortgeführt, in welchem eine „MODIFIZIERE KONTEXT" Anforderung vom Subsystem IA akzeptiert wird, welche zur Registrierung der, vom Subsystem IA mit dieser Anforderung bereitgestellten, Objektreferenzen) oder URI(s) im passendem Sitzungskontextdatenelement SC-W auffordert, das zum ebenfalls vom Subsystem IA bereitgestelltem Deskriptor D gehört.
Der Kontrollfluss geht dann auf Block SCM-52 über, in welchem unter den, vom Sitzungskontextverwalter SCM verwalteten, Sitzungskontextdatenelementen das Sitzungskontextdatenelement ausgewählt wird, dessen DESKRIPTOR ATTRIBUT Wert mit dem, vom Subsystem IA mittels der „MODIFIZIERE KONTEXT" Anforderung bereitgestellten, Deskriptor D übereinstimmt. Dieses ausgewählte Sitzungskontextdatenelement wird im folgendem als Sitzungskontextdatenelement SC-W bezeichnet.
Der Kontrollfluss geht dann auf Block SCM-53 über, in welchem die, vom Subsystem IA bereitgestellte(n), Objektreferenzen) oder URI(s) zum „LISTE DER IMPLIZIT AUTORISIERTEN OBJEKTREFERENZEN / URIS"-Attribut des Sitzungskontextes SC-W hinzugefügt werden.
Die Verarbeitung terminiert im Block SCM-54 und der Kontrollfluss wird an Subsystem IA zurückgegeben.

Claims

Autorisierungs- und Zugriffskontrollverfahren auf Eingangssitzungsbasis zur Kontrolle des Zugriffs von einem Initiatorhost (IH) auf Objekte (Target1, Target2) auf einem Zielhost (TH), mit den folgenden Schritten: (i) Empfangen einer ursprünglich von dem Initiatorhost (IH) kommenden Zugriffsanforderung, vorzugsweise einer Anforderungsnachricht (M1), die ein Objekt (Target1, Target2) auf dem Zielhost (TH), auf das zugegriffen werden soll, referenziert, (ii) Zuweisen der Zugriffsanforderung (M1) zu einer Eingangssitzung und Auswählen eines zu dieser Eingangssitzung gehörenden Sitzungskontextes (SC-U, SC-W, SC-Y), (iii) Prüfen, ob der Zugriff auf das referenzierte Objekt (Target1, Target2) in dem gewählten Sitzungskontext (SC-U, SC-W, SC-Y) autorisiert ist oder nicht, und (iv) Verweigern des Zugriffs auf das referenzierte Objekt (Target1, Target2), wenn der Zugriff auf das Objekt auf dem Zielhost (TH) in dem gewählten Sitzungskontext (SC-U, SC-W, SC-Y) nicht autorisiert ist, (v) Gewähren des Zugriffs auf das referenzierte Objekt (Target1, Target2), wenn der Zugriff auf das Objekt auf dem Zielhost (TH) in dem gewählten Sitzungskontext (SC-U, SC-W, SC-Y) erlaubt ist, wobei Referenzen auf Objekte (Target1, Target2) auf dem Zielhost (TH) als Reaktion auf eine bereits gewährte Zugriffsanforderung an den Initiatorhost (IH) weitergereicht wurden und wobei das Objekt, für das die Referenz weitergereicht wird, für einen Zugriff unter der weitergereichten Referenz in diesem Sitzungskontext (SC-U, SC-W, SC-Y), dem die bereits gewährte Zugriffsanforderung zugewiesen ist, autorisiert ist.
Autorisierungs- und Zugriffskontrollverfahren auf Eingangssitzungsbasis nach Anspruch 1, dadurch gekennzeichnet, daß die Zuweisung der Zugriffsanforderung (M1) zu der Eingangssitzung und die Auswahl des zu dieser Eingangssitzung gehörenden Sitzungskontextes (SC-U, SC-W, SC-Y) von einer zugrundeliegenden Transportsitzung unabhängig sind.
Autorisierungs- und Zugriffskontrollverfahren auf Eingangssitzungsbasis nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß die Zuweisung der Zugriffsanforderung (M1) zu der Eingangssitzung und die Auswahl des zu dieser Eingangssitzung gehörenden Sitzungskontextes (SC-U, SC-W, SC-Y) von der Struktur, dem Format und dem Inhalt der an den Initiatorhost (IH) weitergereichten Objektreferenzen unabhängig sind.
Autorisierungs- und Zugriffskontrollverfahren auf Eingangssitzungsbasis nach Anspruch 1, 2 oder 3, dadurch gekennzeichnet, daß das Objekt, für das die Referenz weitergereicht wird, unter der weitergereichten Referenz in diesem Sitzungskontext (SC-U, SC-W, SC-Y), dem die bereits gewährte Zugriffsanforderung zugewiesen ist, für eine maximale Anzahl von Zugriffen für einen Zugriff autorisiert wird.
Autorisierungs- und Zugriffskontrollverfahren auf Eingangssitzungsbasis nach Anspruch 1, 2, 3 oder 4, dadurch gekennzeichnet, daß das Objekt, für das die Referenz weitergereicht wird, unter der weitergereichten Referenz in diesem Sitzungskontext (SC-U, SC-W, SC-Y), dem die bereits gewährte Zugriffsanforderung zugewiesen ist, für einen Zugriff für einen Zugriffsgültigkeitszeitraum autorisiert wird, so daß während des Zugriffsgültigkeitszeitraums der Zugriff gewährt wird.
Autorisierungs- und Zugriffskontrollverfahren auf Eingangssitzungsbasis nach einem der Ansprüche 1–5, dadurch gekennzeichnet, daß die von dem Initiatorhost (IH) kommende Zugriffsanforderung (M1) über einen sicheren Kommunikationskanal empfangen wird, und zwar bevorzugt über einen Kanal, auf dem die Kommunikation verschlüsselt ist, und zwar ganz besonders bevorzugt durch Verschlüsselung mit einem public-key Kryptosystem.
Autorisierungs- und Zugriffskontrolldatenverarbeitungssystem auf Eingangssitzungsbasis zur Kontrolle des Zugriffs von einem Initiatorhost (IH) auf Objekte (Target1, Target2) auf einem Zielhost (TH), umfassend: – Mittel zum Empfangen einer ursprünglich von dem Initiatorhost (IH) kommenden Zugriffsanforderung, vorzugsweise einer Anforderungsnachricht (M1), die ein Objekt (Target1, Target2) auf dem Zielhost (TH), auf das zugegriffen werden soll, referenziert, – Mittel zum Zuweisen der Zugriffsanforderung (M1) zu einer Eingangssitzung und zum Auswählen eines zu dieser Eingangssitzung gehörenden Sitzungskontextes (SC-U, SC-W, SC-Y), – Mittel zum Prüfen, ob der Zugriff auf das referenzierte Objekt (Target1, Target2) in dem gewählten Sitzungskontext (SC-U, SC-W, SC-Y) autorisiert ist oder nicht, die den Zugriff auf das referenzierte Objekt (Target1, Target2) verweigern, wenn der Zugriff auf das Objekt auf dem Zielhost (TH) in dem gewählten Sitzungskontext (SC-U, SC-W, SC-Y) nicht autorisiert ist, und die den Zugriff auf das referenzierte Objekt (Target1, Target2) gewähren, wenn der Zugriff auf das Objekt auf dem Zielhost (TH) in dem gewählten Sitzungskontext (SC-U, SC-W, SC-Y) erlaubt ist, wobei das System außerdem Mittel umfaßt, die Referenzen auf Objekte (Target1, Target2) auf dem Zielhost (TH) als Reaktion auf eine bereits gewährte Zugriffsanforderung an den Initiatorhost (IH) weiterreichen, und Mittel, die Objekte, für die die Referenz weitergereicht wird, für einen Zugriff unter der weitergereichten Referenz in diesem Sitzungskontext (SC-U, SC-W, SC-Y), dem die bereits gewährte Zugriffsanforderung zugewiesen ist, autorisieren.
Autorisierungs- und Zugriffskontrolldatenverarbeitungssystem auf Eingangssitzungsbasis nach Anspruch 7, dadurch gekennzeichnet, daß die Mittel zum Zuweisen der Zugriffsanforderung (M1) zu einer Eingangssitzung und zum Auswählen eines zu dieser Eingangssitzung gehörenden Sitzungskontextes (SC-U, SC-W, SC-Y) das Zuweisen der Zugriffsanforderung (M1) zu der Eingangssitzung und das Auswählen des zu dieser Eingangssitzung gehörenden Sitzungskontextes (SC-U, SC-W, SC-Y) unabhängig von jeder zugrundeliegenden Transportsitzung durchführen.
Autorisierungs- und Zugriffskontrolldatenverarbeitungssystem auf Eingangssitzungsbasis nach Anspruch 7, dadurch gekennzeichnet, daß die Mittel zum Zuweisen der Zugriffsanforderung (M1) zu einer Eingangssitzung und zum Auswählen eines zu dieser Eingangssitzung gehörenden Sitzungskontextes (SC-U, SC-W, SC-Y) das Zuweisen der Zugriffsanforderung (M1) zu der Eingangssitzung und das Auswählen des zu dieser Eingangssitzung gehörenden Sitzungskontextes (SC-U, SC-W, SC-Y) unabhängig von der Struktur, dem Format und dem Inhalt der an den Initiatorhost (IH) weitergereichten Objektreferenzen durchführen.
Autorisierungs- und Zugriffskontrolldatenverarbeitungssystem auf Eingangssitzungsbasis nach Anspruch 7, 8 oder 9, dadurch gekennzeichnet, daß das System außerdem Mittel umfaßt, die Objekte, für die die Referenz weitergereicht wird, unter der weitergereichten Referenz in diesem Sitzungskontext (SC-U, SC-W, SC-Y), dem die bereits gewährte Zugriffsanforderung zugewiesen ist, für eine maximale Anzahl von Zugriffen für einen Zugriff autorisieren.
Autorisierungs- und Zugriffskontrolldatenverarbeitungssystem auf Eingangssitzungsbasis nach Anspruch 7, 8, 9 oder 10, dadurch gekennzeichnet, daß das System außerdem Mittel umfaßt, die Objekte, für die die Referenz weitergereicht wird, unter der weitergereichten Referenz in diesem Sitzungskontext (SC-U, SC-W, SC-Y), dem die bereits gewährte Zugriffsanforderung zugewiesen ist, für einen Zugriff für einen Zugriffsgültigkeitszeitraum autorisieren, so daß während des Zugriffsgültigkeitszeitraums der Zugriff gewährt wird.
Autorisierungs- und Zugriffskontrolldatenverarbeitungssystem auf Eingangssitzungsbasis nach einem der Ansprüche 7–11, dadurch gekennzeichnet, daß die von dem Initiatorhost (IH) kommende Zugriffsanforderung (M1) über sichere Kommunikationsmittel empfangen wird, und zwar bevorzugt über kryptographische Mittel, die einen sicheren Kanal zu dem Initiatorhost (IH) betreiben.
Autorisierungs- und Zugriffskontrolldatenverarbeitungssystem auf Eingangssitzungsbasis nach einem der Ansprüche 7–12, dadurch gekennzeichnet, daß – der Zielhost (TH) als ein Anwendungsmodul (APP), bevorzugt ein erstes Softwaremodul, mit Zielobjekten (Target1, Target2) implementiert wird, – wobei das Autorisierungs- und Zugriffskontrollsystem als ein Interzeptor auf Anwendungsebene (ALI), bevorzugt ein zweites Softwaremodul, implementiert wird, wobei beides in einem Computersystem, bevorzugt einer Servermaschine, installiert ist.
Autorisierungs- und Zugriffskontrolldatenverarbeitungssystem auf Eingangssitzungsbasis nach einem der Ansprüche 7–13, dadurch gekennzeichnet, daß das Autorisierungs- und Zugriffskontrollsystem als Gateway-Maschine (GWM) in einem Computersystem installiert ist, das Kommunikationsmittel umfaßt, die die Gateway-Maschine (GWM) mit einem externen Netzwerk (EN) und einem internen Netzwerk (IN) verbinden, wobei der Initiatorhost (IH) als Client-Maschine (CM1) mit dem externen Netzwerk (EN) und der Zielhost (IH) als Server-Maschine (SM1) mit dem internen Netzwerk (IN) verbunden ist.
Kommunikationsnetz mit einem Autorisierungs- und Zugriffskontrolldatenverarbeitungssystem auf Eingangssitzungsbasis nach einem der Ansprüche 7–14 mit Bootstrapping-Zielobjekten auf dem Zielhost (TH) als anfänglichen Kontaktpunkten zum Herstellen der Zugriffskommunikation, wobei der Zugriff auf die Bootstrapping-Zielobjekte über explizite Autorisierungsmittel, die von den Mitteln, die prüfen, ob der Zugriff auf das referenzierte Objekt (Target1, Target2) in dem gewählten Sitzungskontext (SC-U, SC-W, SC-Y) autorisiert ist oder nicht, verschieden sind, gewährt oder verweigert wird.
Computerprogramm mit Anweisungen, die so ausgelegt sind, daß sie das Verfahren nach einem der Ansprüche 1 bis 6 ausführen.
Computerprogrammprodukt mit auf einem computerlesbaren Speichermedium gespeicherten Programmcodemitteln zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 6, wenn das Computerprogrammprodukt auf einem Computer ausgeführt wird.
Computerprogrammprodukt mit Programmcodemitteln auf einem Datenträgersignal zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 6, wenn das Computerprogrammprodukt auf einem Computer ausgeführt wird.