-
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,
wobei Referenzen auf Objekte auf dem Zielhost als Reaktion
auf eine bereits gewährte
Zugriffsanforderung an den Initiatoxhost weitergereicht wurden und wobei
das Objekt, für
das die Referenz weitergereicht wird, für einen Zugriff unter der weitergereichten
Referenz in diesem Sitzungskontext, dem die bereits gewährte Zugriffsanforderung
zugewiesen ist, autorisiert ist
eine andere Ausführungsform
der vorliegenden Erfindung.
-
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
über diese
API zur Verfügung
gestellt.
-
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.