DE112010004135T5 - Sicherung Asynchroner Client-Server-Transaktionen - Google Patents

Sicherung Asynchroner Client-Server-Transaktionen Download PDF

Info

Publication number
DE112010004135T5
DE112010004135T5 DE112010004135T DE112010004135T DE112010004135T5 DE 112010004135 T5 DE112010004135 T5 DE 112010004135T5 DE 112010004135 T DE112010004135 T DE 112010004135T DE 112010004135 T DE112010004135 T DE 112010004135T DE 112010004135 T5 DE112010004135 T5 DE 112010004135T5
Authority
DE
Germany
Prior art keywords
application
computer
catalog
service
service identifier
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
DE112010004135T
Other languages
English (en)
Other versions
DE112010004135B4 (de
Inventor
Mary Ellen Zurko
Steven Bade
Harold Moss
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of DE112010004135T5 publication Critical patent/DE112010004135T5/de
Application granted granted Critical
Publication of DE112010004135B4 publication Critical patent/DE112010004135B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

In den veranschaulichenden Ausführungsformen werden ein Verfahren, ein System und ein auf einem Computer verwendbares Programmprodukt zum Sichern von asynchronen Client-Server-Transaktionen bereitgestellt. Eine Anforderung, die eine Anwendungskennung und eine Version einer zweiten Anwendung enthält, wird an einer ersten Anwendung empfangen. Eine Dir zweiten Anwendung gültig ist. In der ersten Anwendung wird eine Registrierdatenbank erzeugt. Auf der Grundlage der Registrierdatenbank wird ein Katalog erzeugt, und die Dienstkennung und der Katalog werden an die zweite Anwendung gesendet. Als Teil einer asynchronen Client-Server-Transaktion wird eine die Dienstkennung enthaltende Unteranforderung empfangen. Die Gültigkeit der Unteranforderung wird ermittelt, indem ermittelt wird, ob die Dienstkennung abgelaufen ist, ob die Unteranforderung einen Dienst anfordert, der gemäß dem Katalog zulässig ist, ob die Dienstkennung in Verbindung mit der zweiten Anwendung verwendet wird, oder durch eine Kombination daraus. Wenn die Unteranforderung gültig ist, wird der Dienst bereitgestellt.

Description

  • HINTERGRUND DER ERFINDUNG
  • Gebiet der Erfindung
  • Die vorliegende Erfindung betrifft allgemein ein verbessertes Datenverarbeitungssystem und insbesondere ein computerimplementiertes Verfahren zum Bereitstellen von Datensicherheit. Insbesondere betrifft die vorliegende Erfindung ein computerimplementiertes Verfahren, System und durch einen Computer verwendbaren Programmcode zum Sichern von asynchronen Client-Server-Transaktionen.
  • Beschreibung der verwandten Technik
  • Daten werden häufig zwischen verschiedenen Datenverarbeitungssystemen unter Verwendung einer oder mehrerer Datennetzwerke ausgetauscht. Einige Datenverarbeitungssysteme können als Client-Datenverarbeitungssysteme angesehen werden, da sie Verbraucher von Daten bzw. Diensten sind. Andere Datenverarbeitungssysteme können als Server-Datenverarbeitungssysteme angesehen werden, da sie die angeforderten Daten bzw. Dienste bereitstellen. Als Client ausgeführte Anwendungen, d. h. als Verbraucher von Daten bzw. Diensten, nennt man Client-Anwendungen. Als Server ausgeführte Anwendungen, d. h. sie stellen Daten bzw. Dienste bereit, nennt man Server-Anwendungen.
  • Die Sicherheit der Daten, der Systeme, auf denen sich die Daten befinden, und der Netzwerke, in denen die Systeme betrieben werden, stellt bei der Datenübertragung ein Problem dar. Üblicherweise wird die Sicherheit eines Datenverarbeitungssystems, von Inhalten des Datenverarbeitungssystems sowie von Netzwerken, in denen das Datenverarbeitungssystem betrieben wird, durch irgendeinen Sicherheitsmechanismus erreicht. Der Identitätsnachweis (authentification) mit Benutzerkennung (UID, user identifier) und Kennwort stellt ein gebräuchliches Verfahren zum Erreichen von sicherheitsbezogenen Zielen in Datenverarbeitungsumgebungen dar.
  • Client- und Server-Datenverarbeitungssysteme können unter Verwendung einer Vielfalt von Protokollen miteinander Daten austauschen. Ein zwischen einem Client- und einem Server-Datenverarbeitungssystem stattfindender Datenaustausch beinhaltet eine Reihe von Anforderungen und Antworten. Miteinander in Beziehung stehende Anforderungen und Antworten bilden eine Transaktion.
  • Die Sicherheit der Client-Server-Transaktionen wird derzeit auf vielfältige Weisen erreicht. Bestimmte Protokolle wie das sichere Hypertext-Übertragungsprotokoll (HTTPS, HyperText Transfer Protocol Secure) erreichen die Sicherheit der Client-Server-Transaktionen durch Verwendung von Verschlüsselung und sicherer Identifizierung der Server-Datenverarbeitungssysteme. Bestimmte andere Sicherheitsmechanismen für Transaktionen umfassen die Verwendung von Sitzungskennungen (session ID). Bei einer Sitzungskennung handelt es sich um eine Kennung, die zum Kennzeichnen einer Sitzung zwischen einem Client- und einem Server-Datenverarbeitungssystem verwendet wird. Eine übliche Sitzung kann eine Reihe von Transaktionen enthalten.
  • In einigen Fällen kann ein Client Daten von einem Server asynchron anfordern. Bei der asynchronen Datenübertragung werden Daten ohne Beeinflussung des Verhaltens einer laufenden Aufgabe (task) übertragen. Bei einer Web-Browser-Anwendung kann es sich zum Beispiel um eine Client-Anwendung handeln. Der Web-Browser kann Daten von einem Web-Server asynchron anfordern, so dass das Verhalten bzw. die Anzeige einer in dem Web-Browser angezeigten Seite nicht durch die asynchrone Datenanforderung bzw. -antwort beeinflusst wird. Eine asynchrone Anforderung wartet auch nicht auf eine entsprechende Antwort. Anders ausgedrückt, eine Antwort auf eine asynchrone Anforderung kann zu jeder beliebigen Zeit an dem Client ankommen und verarbeitet werden. Der Client wartet nicht auf eine Antwort auf eine asynchrone Anforderung, sondern fährt mit dem Bearbeiten anderer Aufgaben fort.
  • Bei einer asynchronen Anforderung handelt es sich um eine Anforderung asynchroner Daten bzw. eines asynchronen Dienstes. Bei einer asynchronen Client-Server-Transaktion handelt es sich um eine Client-Server-Transaktion, die in Bezug auf eine andere laufende Aufgabe asynchron stattfindet.
  • Asynchrones JavaScript und XML (Asynchronous JavaScript and XML, AJAX) stellt eine Technologie dar, die gegenwärtig zum Erstellen und Durchführen von asynchronen Client-Server-Transaktionen verwendet wird. Asynchrone Client-Server-Transaktionen sind besonders nützlich zum Verbessern der Leistungsfähigkeit der Web-Anwendungen und zum Verbessern des Nutzererlebnisses.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Die veranschaulichenden Beispiele stellen ein Verfahren, ein System und ein auf einem Computer verwendbares Programmprodukt zum Sichern von asynchronen Client-Server-Transaktionen bereit. Gemäß einer Ausführungsform wird an einer ersten in einem Datenverarbeitungssystem ausgeführten Anwendung eine Anforderung empfangen. Die Anforderung enthält eine Anwendungskennung und eine Version, die einer zweiten Anwendung zugehörig sind. Eine Dienstkennung wird erzeugt, wenn eine Sitzung mit der zweiten Anwendung gültig ist. In der ersten Anwendung wird eine Registrierdatenbank (registry) erzeugt. Die Registrierdatenbank enthält Informationen über eine Reihe von Diensten und Daten, welche die zweite Anwendung verwenden darf. Auf Grundlage der Registrierdatenbank wird ein Katalog erzeugt. Der Katalog enthält eine Teilmenge der Inhalte der Registrierdatenbank bzw. irgendeiner Umwandlung dieser Inhalte. Die Dienstkennung und der Katalog werden an die zweite Anwendung gesendet.
  • Gemäß einer weiteren Ausführungsform wird eine Unteranforderung empfangen. Bei der Unteranforderung handelt es sich um einen Teil einer asynchronen Client-Server-Transaktion, und sie enthält die Dienstkennung. Die Gültigkeit der Unteranforderung wird ermittelt, indem ermittelt wird, ob die Dienstkennung fällig bzw. abgelaufen ist, ob die Unteranforderung einen Dienst anfordert, der gemäß dem Katalog zulässig ist, ob die Dienstkennung in Verbindung mit der zweiten Anwendung verwendet wird, oder durch eine Kombination daraus. Wenn die Unteranforderung gültig ist, wird als Reaktion auf die Unteranforderung der Dienst bereitgestellt.
  • Gemäß einer weiteren Ausführungsform kann beim Ermitteln der Gültigkeit die Kombination ferner das Ermitteln, ob der Katalog veraltet ist, umfassen.
  • Gemäß einer weiteren Ausführungsform beinhaltet das Ermitteln, ob die Dienstkennung in Verbindung mit der zweiten Anwendung verwendet wird, das Ermitteln, ob die Dienstkennung gemeinsam mit der Anwendungskennung und der Anwendungsversion der zweiten Anwendung verwendet wird.
  • Gemäß einer Ausführungsform werden bei ungültiger Unteranforderung eine erneuerte Dienstkennung, ein erneuerter Katalog bzw. eine Kombination daraus bereitgestellt. Die Unteranforderung kann dann mit der erneuerten Dienstkennung, dem erneuerten Katalog oder einer Kombination daraus wiederholt werden.
  • Gemäß einer weiteren Ausführungsform kann es sich bei der erneuerten Dienstkennung um eine neue Dienstkennung handeln, die Dienstkennung kann ein abgeändertes Sicherheitsmerkmal enthalten, die Dienstkennung kann einer Abänderung des Kriteriums zum Prüfen der Gültigkeit des Sicherheitsmerkmals in der ersten Anwendung entsprechen, oder eine Kombination daraus. Eine Unteranforderung kann mit der erneuerten Dienstkennung wiederholt werden. Das Bereitstellen in einer derartigen Ausführungsform findet vor dem Abschließen der asynchronen Client-Server-Transaktion statt.
  • Gemäß einer weiteren Ausführungsform kann es sich bei dem erneuerten Katalog um einen neuen Katalog, eine Aktualisierung des Katalogs, eine Abänderung eines Fälligkeitsparameters des Katalogs oder eine Kombination daraus handeln. Eine Unteranforderung kann mit dem erneuerten Katalog wiederholt werden. In einer derartigen Ausführungsform findet das Bereitstellen vor dem Abschließen der asynchronen Client-Server-Transaktion statt.
  • Gemäß einer weiteren Ausführungsform wird ermittelt, ob der Dienst einen zusätzlichen Identitätsnachweis benötigt. Wenn ein zusätzlicher Identitätsnachweis benötigt wird, werden als Reaktion auf eine Anforderung nach zusätzlichen Identitätsnachweisdaten zusätzliche Identitätsnachweisdaten empfangen. Die Ausführungsform ermittelt, ob die zusätzlichen Identitätsnachweisdaten gültig sind. Der Dienst wird bereitgestellt, wenn die zusätzlichen Identitätsnachweisdaten gültig sind.
  • Gemäß einer weiteren Ausführungsform wird das Ermitteln, ob der Dienst gemäß dem Katalog zulässig ist, durchgeführt, indem unter Verwendung der Registrierdatenbank ermittelt wird, ob der Dienst zulässig ist.
  • Gemäß einer weiteren Ausführungsform wird eine anfängliche Dienstkennung erzeugt. Bei der Dienstkennung handelt es sich um eine umgewandelte Version der anfänglichen Dienstkennung.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Ausführungsformen der vorliegenden Erfindung werden nun lediglich beispielhaft unter Bezugnahme auf die beigefügten Zeichnungen beschrieben. Es zeigen:
  • 1 eine bildliche Darstellung eines Netzwerks eines Datenverarbeitungssystems, in dem veranschaulichende Ausführungsformen umgesetzt werden können;
  • 2 ein Blockschaltbild eines Datenverarbeitungssystems, in dem veranschaulichende Ausführungsformen umgesetzt werden können;
  • 3 ein Blockschaltbild einer Datenverarbeitungsumgebung, in der eine veranschaulichende Ausführungsform umgesetzt werden kann;
  • 4 ein Blockschaltbild einer Konfiguration eines Server-Datenverarbeitungssystems zum Sichern von asynchronen Client-Server-Transaktionen gemäß einer veranschaulichenden Ausführungsform;
  • 5 ein Blockschaltbild einer Konfiguration eines Client-Datenverarbeitungssystems zum Sichern von asynchronen Client-Server-Transaktionen gemäß einer veranschaulichenden Ausführungsform;
  • 6 ein Zeitablaufdiagramm von Transaktionen, die in einer asynchronen Client-Server-Transaktion gemäß einer veranschaulichenden Ausführungsform stattfinden;
  • 7 ein Blockschaltbild eines Prozesses zum Erneuern einer Dienstkennung und eines Katalogs gemäß einer veranschaulichenden Ausführungsform;
  • 8 einen Ablaufplan eines Prozesses zum Erzeugen einer Registrierdatenbank, einer Dienstkennung und eines Katalogs gemäß einer veranschaulichenden Ausführungsform;
  • 9 einen Ablaufplan eines Prozesses zum Sichern von asynchronen Client-Server-Transaktionen gemäß einer veranschaulichenden Ausführungsform; und
  • 10 einen Ablaufplan eines anderen Prozesses zum Sichern von asynchronen Client-Server-Transaktionen gemäß einer veranschaulichenden Ausführungsform.
  • AUSFÜHRLICHE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM
  • Die Erfindung erkennt, dass ein Client im Rahmen einer asynchronen Client-Server-Transaktion mehrere Unteranforderungen durchführen kann. Unter Verwendung der gegenwärtig verfügbaren Technologie für asynchrone Client-Server-Transaktionen kann ein Client einem Server einmalig seine Identität bekanntgeben und dann mehrere Unteranforderungen beantragen sowie verschiedene von dem Server angebotene Dienste durchlaufen. Der Client kann Zugriff auf Dienste erhalten, die ohne Beziehung zu der Transaktion oder dem Betrieb des Clients sind. Bösartige Anwendungen können eine legitime asynchrone Client-Server-Transaktion eines Clients ausnutzen, um Zugriff auf Dienste und Daten auf dem Server zu erhalten, nachdem der anfängliche Identitätsnachweis erfolgreich verlief.
  • Die Technik mit Sitzungskennungen ist für das Verhindern dieser Arten von Überschreitungen untauglich. Die Technik mit Sitzungskennungen ist unzureichend, da die Sitzungskennung während einer Sitzung allgemein unverändert bleibt und beruhend auf anderen Sitzungsparametern auch leicht erraten werden kann. Andere derzeit verfügbare Technologien sind ebenfalls untauglich für das Verhindern von Zugriff auf in keinem Zusammenhang stehende Dienste bzw. Daten und für das Verhindern des Entführens (hijacking) asynchroner Client-Server-Transaktionen für eine bösartige Verwendung.
  • Die zur Beschreibung der Erfindung verwendeten veranschaulichenden Ausführungsformen gehen die oben beschriebenen Probleme und andere mit der Sicherheit in asynchronen Client-Server-Transaktionen zusammenhängende Probleme an und lösen diese. Die veranschaulichenden Ausführungsformen stellen ein Verfahren, ein auf einem Computer verwendbares Programmprodukt und ein Datenverarbeitungssystem zum Sichern von asynchronen Client-Server-Transaktionen bereit.
  • Die veranschaulichenden Ausführungsformen werden in Bezug auf bestimmte Transaktionen, Daten, Datenstrukturen, Anforderungen sowie Antworten lediglich als Beispiele beschrieben. Derartige Beschreibungen sollen die Erfindung nicht einschränken. Eine in Bezug auf eine AJAX-Transaktion beschriebene veranschaulichende Ausführungsform kann zum Beispiel auf eine asynchrone Client-Server-Transaktion angewendet werden, wenn eine andere vergleichbare Technologie, ein Format oder Standard auf gleichartige Weise innerhalb des Umfangs der Erfindung verwendet wird.
  • Des Weiteren werden die veranschaulichenden Ausführungsformen lediglich der Klarheit der Beschreibung halber in Bezug auf spezifische Client- und Server-Datenverarbeitungssysteme und anwendungen beschrieben. Ohne von dem Umfang der Erfindung abzuweichen, können die veranschaulichenden Ausführungsformen in Bezug auf jede beliebige andere Art von Datenverarbeitungssystem, Daten, Datenquelle oder Zugriff auf eine Datenquelle umgesetzt werden, die als Clients und Server dienen können. Eine Ausführungsform der Erfindung kann in Bezug auf jede beliebige Art von Anwendungen umgesetzt werden, wie zum Beispiel jede beliebige Art von Client-Anwendungen, Server-Anwendungen, Plattform-Anwendungen, eigenständigen Anwendungen oder eine Kombination daraus.
  • Eine Anwendung kann ferner Datenobjekte, Code-Objekte, verkapselte Anweisungen, Anwendungsfragmente, Dienste sowie andere Arten von in einer Datenverarbeitungsumgebung vorhandenen Ressourcen enthalten. Ein Java®-Objekt, ein Enterprise Java Bean (EJB®), ein Servlet oder ein Applet können zum Beispiel Erscheinungsformen einer Anwendung sein, in Bezug auf welche, innerhalb welcher oder unter Verwendung welcher die Erfindung umgesetzt werden kann. (Java, EJB und andere mit Java in Zusammenhang stehende Fachausdrücke sind registrierte Marken von Oracle und/oder ihren zugehörigen Unternehmen.)
  • Eine veranschaulichende Ausführungsform kann in Hardware, Software oder einer Kombination daraus umgesetzt werden. Die hierin beschriebenen Beispiele werden lediglich der Klarheit der Beschreibung halber verwendet und schränken die veranschaulichenden Ausführungsformen nicht ein. Aus dieser Beschreibung sind zusätzliche oder unterschiedliche Informationen, Daten, Arbeitsschritte, Aktionen, Aufgaben, Aktivitäten und Bearbeitungsvorgänge für gleichartige Zwecke denkbar, und diese sind innerhalb des Umfangs der veranschaulichenden Ausführungsformen vorgesehen.
  • Die veranschaulichenden Ausführungsformen werden unter Verwendung spezifischer Kennungen, Parameter, Attribute, Konfigurationen, Codes, Datenstrukturen, Dateisysteme, Bauformen, Architekturen, Anordnungen, Schaltbilder und Tools lediglich als Beispiele beschrieben und schränken die veranschaulichenden Ausführungsformen nicht ein. Des Weiteren werden die veranschaulichenden Ausführungsformen in einigen Fällen unter Verwendung bestimmter Software-Tools sowie Datenverarbeitungsumgebungen lediglich als Beispiel der Klarheit der Beschreibung halber beschrieben. Die veranschaulichenden Ausführungsformen können in Verbindung mit anderen vergleichbaren oder gleichartigen Zwecken dienenden Strukturen, Systemen, Anwendungen oder Architekturen verwendet werden.
  • Jegliche hierin aufgeführten Vorteile sind lediglich Beispiele und sollen die veranschaulichenden Ausführungsformen nicht einschränken. Zusätzliche oder unterschiedliche Vorteile können durch spezielle veranschaulichende Ausführungsformen realisiert werden. Des Weiteren kann eine bestimmte veranschaulichende Ausführungsform einige, alle oder keine der oben aufgeführten Vorteile aufweisen.
  • Unter Bezugnahme auf die Figuren, und insbesondere unter Bezugnahme auf die 1 und 2, stellen diese Figuren Beispielsschaubilder von Datenverarbeitungsumgebungen dar, in denen veranschaulichende Ausführungsformen umgesetzt werden können. Bei den 1 und 2 handelt es sich lediglich um Beispiele, die keinerlei Einschränkungen in Bezug auf die Umgebungen, in denen verschiedene Ausführungsformen umgesetzt werden können, anführen oder mit sich bringen sollen. Bei einer bestimmten Umsetzung können auf der Grundlage der folgenden Beschreibung viele Abwandlungen an den abgebildeten Umgebungen vorgenommen werden.
  • 1 zeigt eine bildliche Darstellung eines Netzwerks eines Datenverarbeitungssystems, in dem veranschaulichende Ausführungsformen umgesetzt werden können. Bei der Datenverarbeitungsumgebung 100 handelt es sich um ein Netzwerk aus Computern, in dem die veranschaulichenden Ausführungsformen umgesetzt werden können. Die Datenverarbeitungsumgebung 100 beinhaltet das Netzwerk 102. Bei dem Netzwerk 102 handelt es sich um das Medium, das für die Bereitstellung von Datenübertragungsverbindungen zwischen verschiedenen Einheiten und Computern verwendet wird, die innerhalb der Datenverarbeitungsumgebung 100 miteinander verbunden sind. Das Netzwerk 102 kann Verbindungen wie Draht, drahtlose Datenübertragungsverbindungen oder Lichtwellenleiter-Kabel umfassen. Der Server 104 und der Server 106 sind zusammen mit der Speichereinheit 108 mit dem Netzwerk 102 verbunden. Software-Anwendungen können auf jedem beliebigen Computer in der Datenverarbeitungsumgebung 100 ausgeführt werden.
  • Außerdem sind die Clients 110, 112 und 114 mit dem Netzwerk 102 verbunden. Ein Datenverarbeitungssystem wie der Server 104 oder 106 bzw. der Client 110, 112 oder 114 kann Daten enthalten, und es können Software-Anwendungen oder Software-Tools darauf ausgeführt werden.
  • Der Server 104 kann den Anwendungsserver 105 enthalten. Bei dem Anwendungsserver 105 kann es sich um jede beliebige Anwendung handeln, die betrieben wird, um andere Anwendungen und Dienste anzubieten. Der Server 106 kann den Dienst 107 enthalten. Bei dem Dienst 107 kann es sich um eine Funktion, Operation oder eine Anwendung handeln, die Daten bearbeitet, Daten bereitstellt oder eine Kombination daraus durchführt. Der Client 112 kann die Client-Anwendung 113 enthalten. Bei der Client-Anwendung 113 kann es sich um eine Anwendung oder eine Komponente davon handeln, die in der Lage ist, asynchrone Client-Server-Transaktionen gemäß einer Ausführungsform der Erfindung durchzuführen.
  • Die Server 104 und 106, die Speichereinheit 108 und die Clients 110, 112 und 114 können unter Verwendung von verdrahteten Verbindungen, drahtlosen Datenübertragungsprotokollen oder anderen geeigneten Datenübertragungsmöglichkeiten mit dem Netzwerk 102 verbunden sein. Bei den Clients 110, 112 und 114 kann es sich zum Beispiel um Personal Computer oder Netzwerk-Computer handeln.
  • In dem abgebildeten Beispiel kann der Server 104 den Clients 110, 112 und 114 Daten wie Startdateien, Betriebssystemabbilder sowie Anwendungen bereitstellen. Bei den Clients 110, 112 und 114 kann es sich in diesem Beispiel um Clients des Servers 104 handeln. Die Clients 110, 112, 114 bzw. eine Kombination daraus können ihre eigenen Daten, Startdateien, Betriebssystemabbilder und Anwendungen enthalten. Die Datenverarbeitungsumgebung 100 kann zusätzliche Server, Clients und andere Einheiten umfassen, die nicht gezeigt sind.
  • In dem abgebildeten Beispiel kann es sich bei der Datenverarbeitungsumgebung 100 um das Internet handeln. Das Netzwerk 102 kann eine Sammlung von Netzwerken und Schnittstellen darstellen, die zur Kommunikation untereinander das Transmission Control Protocol/Internet Protocol (TCP/IP) sowie andere Protokolle verwenden. Im Zentrum des Internet liegt ein Hauptstrang von Datenübertragungsverbindungen zwischen Hauptknoten bzw. Host-Computern, darunter tausende kommerzielle, Regierungs-, Bildungs- sowie andere Computersysteme, die Daten und Nachrichten weiterleiten. Natürlich kann die Datenverarbeitungsumgebung 100 auch als eine Reihe verschiedener Arten von Netzwerken wie einem Intranet, einem lokalen Netzwerk (LAN) oder einem Weitverkehrsnetz (WAN) ausgeführt sein. 1 soll als Beispiel und nicht als Einschränkung hinsichtlich des Aufbaus der verschiedenen veranschaulichenden Ausführungsformen dienen.
  • Neben anderen Verwendungsarten kann die Datenverarbeitungsumgebung 100 zum Realisieren einer Client-Server-Umgebung verwendet werden, in der die veranschaulichenden Ausführungsformen umgesetzt werden können. Eine Client-Server-Umgebung gestattet es, Software-Anwendungen und Daten über ein Netzwerk zu verteilen, so dass eine Anwendung durch Nutzung der Datenaustauschmöglichkeiten zwischen einem Client-Datenverarbeitungssystem und einem Server-Datenverarbeitungssystem funktioniert. Die Datenverarbeitungsumgebung 100 kann ebenfalls eine serviceorientierte Architektur einsetzen, in der über ein Netzwerk verteilte, dialogfähige Software-Komponenten zu einheitlichen Geschäftsanwendungen zusammengefasst werden können.
  • 2 zeigt ein Blockschaltbild eines Datenverarbeitungssystems, in dem veranschaulichende Ausführungsformen umgesetzt werden können. Das Datenverarbeitungssystem 200 ist ein Beispiel für einen Computer, zum Beispiel den Server 104 oder den Client 110 in 1, in dem sich für die veranschaulichenden Ausführungsformen durch einen Computer verwendbarer Programmcode bzw. Anweisungen befinden können, welche die Prozesse der veranschaulichenden Ausführungsformen umsetzen.
  • In dem abgebildeten Beispiel setzt das Datenverarbeitungssystem 200 eine Knotenarchitektur (hub architecture) ein, die eine North Bridge bzw. einen Speichersteuerungsknoten (NB/MCH) 202 und eine South Bridge bzw. einen Eingabe-Ausgabe-(E/A-)Steuerungsknoten (SB/ICH) 204 enthält. Die Verarbeitungseinheit 206, der Hauptspeicher 208 und der Grafikprozessor 210 sind mit der North Bridge bzw. dem Speichersteuerungsknoten (NB/MCH) 202 verbunden. Die Verarbeitungseinheit 206 kann einen oder mehrere Prozessoren enthalten und unter Verwendung einer oder mehrerer heterogener Prozessorsysteme ausgeführt sein. Der Grafikprozessor 210 kann in bestimmten Ausführungen über einen beschleunigten Grafikanschluss (AGP, accelerated graphics port) mit dem NB/MCH verbunden sein.
  • In dem abgebildeten Beispiel ist der lokale Netzwerk-(LAN-)Adapter 212 mit der South Bridge und dem E/A-Steuerungsknoten (SB/ICH) 204 verbunden. Der Audio-Adapter 216, der Tastatur- und Mausadapter 220, der Modem 222, der Nur-Lese-Speicher (ROM) 224, der universelle serielle Bus (USB) und andere Anschlüsse 232 sowie die PCI/PCIe-Einheiten 234 sind über den Bus 238 mit der South Bridge bzw. dem E/A-Steuerungsknoten 204 verbunden. Das Festplattenlaufwerk (HDD) 226 und das CD-ROM-Laufwerk 230 sind über den Bus 240 mit der South Bridge bzw. dem E/A-Steuerungsknoten 204 verbunden. PCI/PCIe-Einheiten können zum Beispiel Ethernet-Adapter, Zusatz-Einbaukarten sowie PC-Karten für Notebook-Computer umfassen. PCI verwendet im Gegensatz zu PCIe eine Kartenbussteuereinheit. Bei dem ROM 224 kann es sich zum Beispiel um ein Flash-Basic-Input/Output-System (BIOS) handeln. Das Festplattenlaufwerk 226 und das CD-ROM-Laufwerk 230 können zum Beispiel eine IDE-Schnittstelle (Festplatten-Schnittstelle – Integrated Drive Electronics) oder SATA-Schnittstelle (serielle Schnittstelle zwischen Prozessor und Festplatte – Serial Advanced Technology Attachment) verwenden. Eine Super-E/A-Einheit (SIO-Einheit) 236 kann mit der South Bridge bzw. dem E/A-Steuerungsknoten (SB/ICH) 204 verbunden sein.
  • Auf der Verarbeitungseinheit 206 läuft ein Betriebssystem. Das Betriebssystem koordiniert und sorgt für die Steuerung verschiedener Komponenten innerhalb des Datenverarbeitungssystems 200 in 2. Bei dem Betriebssystem kann es sich um ein marktübliches Betriebssystem wie Microsoft® Windows® (Microsoft und Windows sind Marken von Microsoft Corporation in den USA und anderen Ländern) oder Linux® (Linux ist eine Marke von Linus Torvalds in den USA und anderen Ländern) handeln. Ein objektorientiertes Programmiersystem wie das JavaTM-Programmiersystem kann in Verbindung mit dem Betriebssystem laufen und stellt Betriebssystemaufrufe von auf dem Datenverarbeitungssystem 200 laufenden JavaTM-Programmen oder -Anwendungen bereit.
  • Auf Speichereinheiten wie dem Festplattenlaufwerk 226 befinden sich Anweisungen für das Betriebssystem, das objektorientierte Programmiersystem sowie für Anwendungen bzw. Programme, die zur Ausführung durch die Verarbeitungseinheit 206 in den Hauptspeicher 208 geladen werden können. Die Prozesse der veranschaulichenden Ausführungsformen können von der Verarbeitungseinheit 206 unter Verwendung von computerimplementierten Anweisungen durchgeführt werden, die sich in einem Speicher wie dem Hauptspeicher 208, dem Nur-Lese-Speicher 224 oder in einer oder mehreren Peripherie-Einheiten befinden können.
  • Die Hardware in den 1 bis 2 kann abhängig von der Ausführung unterschiedlich sein. Zusätzlich oder an Stelle der in den 1 bis 2 abgebildeten Hardware können andere interne Hardware- oder Peripherie-Einheiten wie Flash-Speicher, gleichwertige nichtflüchtige Speicher bzw. optische Plattenlaufwerke und dergleichen verwendet werden. Außerdem können die Prozesse aus den veranschaulichenden Ausführungsformen auf ein Datenverarbeitungssystem mit mehreren Prozessoren angewendet werden.
  • In einigen veranschaulichenden Beispielen kann es sich bei dem Datenverarbeitungssystem 200 um einen elektronischen Assistenten (PDA, personal digital assistant) handeln, der allgemein mit Flash-Speichern konfiguriert ist, um einen nichtflüchtigen Speicher zur Speicherung von Betriebssystemdateien und/oder durch einen Benutzer erzeugten Daten bereitzustellen. Ein Bus-System kann einen oder mehrere Busse wie einen Systembus, einen E/A-Bus und einen PCI-Bus umfassen. Natürlich kann das Bussystem unter Verwendung eines beliebigen Datenübertragungsnetzes bzw. einer Architektur ausgeführt sein, die eine Übertragung von Daten zwischen verschiedenen an das Netzwerk bzw. die Architektur angeschlossenen Komponenten oder Einheiten gewährleistet.
  • Eine Datenübertragungseinheit kann eine oder mehrere für das Senden und Empfangen von Daten verwendete Einheiten wie einen Modem oder einen Netzwerkadapter enthalten. Bei einem Speicher kann es sich zum Beispiel um den Hauptspeicher 208 oder einen Cache-Speicher wie den in der North Bridge und dem Speichersteuerungsknoten 202 enthaltenen Cache-Speicher handeln. Eine Verarbeitungseinheit kann einen oder mehrere Prozessoren bzw. CPUs enthalten.
  • Die in den 1 bis 2 abgebildeten und oben beschriebenen Beispiele sollen keine Einschränkungen hinsichtlich des Aufbaus bedeuten. Bei dem Datenverarbeitungssystem 200 kann es sich nicht nur um einen PDA, sondern auch um einen Tablet-Computer, einen Laptop-Computer oder eine Telefoneinheit handeln.
  • 3 zeigt ein Blockschaltbild einer Datenverarbeitungsumgebung, in der eine veranschaulichende Ausführungsform umgesetzt werden kann. Das Client-Datenverarbeitungssystem 302 kann gleichartig wie der Client 112 in 1 sein. Die Client-Anwendung 304 kann gleichartig wie die Client-Anwendung 113 in 1 sein. Das Server-Datenverarbeitungssystem 306 kann gleichartig wie der Server 104 in 1 sein. Der Anwendungsserver 308 kann gleichartig wie der Anwendungsserver 105 in 1 sein.
  • Wie bei der gegenwärtig verwendeten Technologie bezüglich asynchroner Client-Server-Transaktionen kann die Client-Anwendung 304 bei dem Anwendungsserver 308 eine anfängliche asynchrone Anforderung beantragen, auf die eine oder mehrere Unteranforderungen folgen. Die Unteranforderungen können sich auf das Verwenden des berechtigten Dienstes 310, das Zugreifen auf berechtigte Daten 312 oder beides beziehen.
  • Als Beispiel kann es sich bei der bösartigen Anwendung 314 um eine Anwendung auf dem Client-Datenverarbeitungssystem 302 handeln, welche die Transaktionsinformationen zwischen der Client-Anwendung 304 und dem Anwendungsserver 308 fälschen und Unteranforderungen beantragen kann, die der bösartigen Anwendung 314 Zugriff auf den geschützten Dienst 316, die geschützten Daten 318 oder beides gewähren können.
  • Man beachte, dass es sich bei der bösartigen Anwendung 314 um jede beliebige Anwendung mit jedem beliebigen Zweck handeln kann, die sich aber auf diese Weise verhält. Tatsächlich kann sich die Client-Anwendung 302 unter bestimmten Umständen selbst als bösartige Anwendung 314 verhalten und auf diese Weise auf geschützte Ressourcen zugreifen.
  • Bei dem berechtigten Dienst 310 und den berechtigten Daten 312 kann es sich um jeden beliebigen Dienst bzw. beliebige Daten handeln, auf welche die Client-Anwendung 302 im Rahmen einer gegebenen asynchronen Client-Server-Transaktion legitim zugreifen kann. Bei dem berechtigten Dienst 310 und den berechtigten Daten 312 handelt es sich um Beispiele von Diensten bzw. Daten, die auf dem Server-Datenverarbeitungssystem 306 verfügbar sind und sich außerhalb des Gültigkeitsbereichs einer gegebenen asynchronen Client-Server-Transaktion befinden können.
  • 4 zeigt ein Blockschaltbild einer Konfiguration eines Server-Datenverarbeitungssystems zum Sichern von asynchronen Client-Server-Transaktionen gemäß einer veranschaulichenden Ausführungsform. Das Server-Datenverarbeitungssystem 402 kann unter Verwendung des Server-Datenverarbeitungssystems 306 in 3 realisiert werden. Der Anwendungsserver 404 kann unter Verwendung des Anwendungsservers 308 in 3 realisiert werden.
  • Der Anwendungsserver 404 verwendet das Identitätsnachweismodul 406, um die Identität einer anfänglichen Anforderung festzustellen, die in Verbindung mit einer asynchronen Client-Server-Transaktion von einer Client-Anwendung empfangen werden kann. Üblicherweise enthält die anfängliche Anforderung eine der Client-Anwendung zugehörige Anwendungskennung und eine Anwendungsversion der Client-Anwendung. Die anfängliche Anforderung kann ebenfalls beliebige Benutzeridentitätsnachweise wie eine Benutzerkennung und ein Kennwort enthalten.
  • Gemäß einer veranschaulichenden Ausführungsform ermittelt das Identitätsnachweismodul 406 die Identität der Client-Anwendung, falls zutreffend des Benutzers. Bei erfolgreichem Identitätsnachweis stellt das Identitätsnachweismodul 406 dem Anwendungsserver 404 Informationen bereit, die es dem Anwendungsserver 404 ermöglichen, die Registrierdatenbank 408 zu erzeugen.
  • Bei der Registrierdatenbank 408 handelt es sich um eine Auflistung von Aktivitäten, zu deren Durchführung auf dem Server-Datenverarbeitungssystem 402 die Client-Anwendung berechtigt ist. Die Registrierdatenbank 408 kann zum Beispiel Kennungen oder Parameter einer Reihe von auf dem Server-Datenverarbeitungssystem 402 verfügbaren Diensten enthalten, auf welche die berechtigte Client-Anwendung zugreifen darf. Bei einer Reihe von Diensten handelt es sich um einen von mehreren Diensten.
  • Als weiteres Beispiel kann die Registrierdatenbank 408 Parameter enthalten, die Teile einer Datenbank festlegen, die von der identifizierten Client-Anwendung abgefragt werden dürfen. Als weiteres Beispiel kann die Registrierdatenbank 408 negative Parameter oder Kennungen enthalten, das heißt, Parameter oder Kennungen einer Reihe von Diensten und Daten, die von der berechtigten Client-Anwendung nicht verwendet werden dürfen. Bei einer Reihe von Diensten und Daten handelt es sich um einen oder mehrere Dienste bzw. Daten.
  • Diese beispielhaften Einträge in der Registrierdatenbank 408 werden lediglich der Klarheit der veranschaulichenden Ausführungsformen halber beschrieben und schränken die Erfindung nicht ein. Es können im Rahmen des Schutzumfangs der Erfindung viele andere Arten von Informationen mit gleichartigen Zwecken in der Registrierdatenbank 408 eingetragen sein.
  • Nach dem Feststellen der Identität der Client-Anwendung erzeugt das Identitätsnachweismodul 406 in Kombination mit dem Anwendungsserver 404 die Dienstkennung (service ID) 410. Bei der Dienstkennung 410 handelt es sich um eine eindeutige Kennung, die der asynchronen Client-Server-Transaktion oder einem Teil davon zugehörig ist.
  • Der Anwendungsserver 404 sendet die Dienstkennung 410 und den Katalog 412 als Reaktion auf die anfängliche Anforderung der Client-Anwendung zurück an die Client-Anwendung, deren Identität nachgewiesen wurde. Der Katalog 412 enthält eine Teilmenge der Inhalte der Registrierdatenbank 408. In einer Ausführungsform kann der Katalog 412 einige oder alle der Informationen der Registrierdatenbank 408 in einem Format oder einer Datenstruktur enthalten, die sich von dem Format bzw. der Datenstruktur in der Registrierdatenbank 408 unterscheidet. Anders ausgedrückt, die Inhalte des Katalogs 412 können gleichartig wie oder eine Umwandlung von einigen oder allen der Inhalte der Registrierdatenbank 408 sein, wie durch Block 414 gezeigt ist.
  • Block 414 stellt einige oder alle der Inhalte der Registrierdatenbank 408 dar, die zum Aufbauen des Katalogs 412 verwendet werden können. In einer Ausführungsform können die Inhalte des Blocks 414 in unveränderter Form in dem Katalog 412 auftauchen. In einer anderen Ausführungsform können die Inhalte des Blocks 414 zum Beispiel durch Verdichtung, Verschlüsselung oder Umstrukturierung umgewandelt sein, wenn sie in dem Katalog 412 erscheinen.
  • In einer Ausführungsform kann die Dienstkennung 410 mit bestimmten Sicherheitsmerkmalen verbunden sein. Die Dienstkennung 410 kann zum Beispiel lediglich für eine vorbestimmte Zeitspanne während der asynchronen Client-Server-Transaktion gültig sein und danach erneuert werden müssen. Als weiteres Beispiel kann die Dienstkennung 410 lediglich für eine vorbestimmte Anzahl von Unteranforderungen in der asynchronen Client-Server-Transaktion gültig sein und danach erneuert werden müssen.
  • Auf die Dienstkennung 410 kann innerhalb des Umfangs der Erfindung jedes beliebige andere Sicherheitsmerkmal wie eine Verschlüsselung angewendet werden, wenn dies für eine bestimmte Ausführung geeignet ist. Die Funktion und die Art der Dienstkennung 410 sind ausführlich in Bezug auf die 6 und 7 beschrieben.
  • In einer Ausführungsform kann der Katalog 412 von dynamischer Art sein. Anders ausgedrückt, Inhalte des Katalogs 412 können sich während der asynchronen Client-Server-Transaktion ändern, für die der Katalog 412 erstellt wird. In einer Ausführungsform kann der Katalog 412 zum Beispiel lediglich für eine vorbestimmte Zeitspanne gültig bleiben und kann danach aktualisiert werden müssen. Als weiteres Beispiel in einer anderen Ausführungsform kann der Katalog 412 lediglich Informationen enthalten, die für bestimmte Arten oder eine bestimmte Anzahl von erwarteten Unteranforderungen ausreicht, und kann danach für zusätzliche Arten oder eine Anzahl von Unteranforderungen mit Informationen aktualisiert oder erneuert werden.
  • Diese beispielhaften Konfigurationen des Katalogs 412 sollen die Erfindung nicht einschränken. Auf den Katalog 412 kann innerhalb des Umfangs der Erfindung jedes beliebige andere Sicherheitsmerkmal wie eine Verschlüsselung angewendet werden, wenn dies für eine bestimmte Ausführung geeignet ist. Die Funktion und die Art des Katalogs 412 sind ausführlich in Bezug auf die 6 und 7 beschrieben.
  • Lediglich als beispielhafte Konfiguration sind der Anwendungsserver 404, das Identitätsnachweismodul 406 und die Registrierdatenbank 408 als innerhalb des Server-Datenverarbeitungssystems 402 befindlich gezeigt. Eine Umsetzung einer Ausführungsform der Erfindung kann innerhalb des Schutzumfangs der Erfindung diese Komponenten in einer beliebigen Kombination über verschiedene Datenverarbeitungssysteme in einer Datenverarbeitungsumgebung verteilen.
  • 5 zeigt ein Blockschaltbild einer Konfiguration eines Client-Datenverarbeitungssystems zum Sichern von asynchronen Client-Server-Transaktionen gemäß einer veranschaulichenden Ausführungsform. Das Client-Datenverarbeitungssystem 502 kann unter Verwendung des Client-Datenverarbeitungssystems 302 in 3 realisiert werden. Die Client-Anwendung 504 kann unter Verwendung der Client-Anwendung 304 in 3 realisiert werden. Die bösartige Anwendung 506 kann analog zu der bösartigen Anwendung 314 in 3 sein. Die Dienstkennung 508 kann unter Verwendung der Dienstkennung 410 in 4 realisiert werden. Der Katalog 510 kann unter Verwendung des Katalogs 412 in 4 realisiert werden.
  • Die Client-Anwendung 504 kann, wie in Bezug auf 4 beschrieben, eine anfängliche Anforderung nach einer asynchronen Client-Server-Transaktion an einen Anwendungsserver übertragen. Die Client-Anwendung 504 kann die der Client-Anwendung 504 zugehörige Anwendungskennung 512 und Anwendungsversion 514 in der Anforderung enthalten. Optional kann die Client-Anwendung 504, falls zutreffend, auch einem Benutzer zugehörige Identitätsnachweisdaten enthalten. Bei erfolgreichem Identitätsnachweis unter Verwendung der Identitätsnachweisdaten der Anforderung gegenüber dem Anwendungsserver empfängt die Client-Anwendung 504 als Reaktion auf die Anforderung die Dienstkennung 508 und den Katalog 510.
  • In einer Ausführungsform kann die Client-Anwendung 504 auch aktuell genutzte Kennungen und Informationen wie eine Sitzungskennung empfangen. Wie oben beschrieben, kann die bösartige Anwendung 506 in der Lage sein, derartige aktuell genutzte Kennungen und Informationen zu erraten oder zu fälschen. Vorteilhafterweise sind die Struktur und Art der Verwendung der Dienstkennung 508 und des Katalogs 510 beim Fortführen der asynchronen Client-Server-Transaktion nicht anfällig für eine gleichartige Verwendung durch die bösartige Anwendung 506.
  • In einer Ausführungsform wird in einer Unteranforderung eine Kombination aus der Anwendungskennung 512, der Anwendungsversion 514, der Dienstkennung 508 und der Inhalte des Katalogs 510 verwendet. Diese Kombination wird beim dynamischen Erstellen der Unteranforderung gemäß einer Ausführungsform verwendet, im Gegensatz zu festen oder vorcodierten Unteranforderungen wie nach dem Stand der Technik. Der dynamische Aufbau der Unteranforderung und die Kombination aus der Anwendungskennung 512, der Anwendungsversion 514, der Dienstkennung 508 und der Inhalte des Katalogs 510 ermöglichen es einer Ausführungsform der Erfindung, Sicherheit der asynchronen Client-Server-Transaktion und der darin enthaltenen Unteranforderungen zu erreichen, die mit der gegenwärtig verfügbaren Technologie für asynchrone Client-Server-Transaktionen nicht verfügbar ist.
  • 6 zeigt ein Zeitablaufdiagramm von Transaktionen, die in einer asynchronen Client-Server-Transaktion gemäß einer veranschaulichenden Ausführungsform stattfinden. Die Client-Anwendung 602 kann unter Verwendung der Client-Anwendung 502 in 5 realisiert werden. Der Anwendungsserver 604 kann unter Verwendung des Anwendungsservers 404 in 4 realisiert werden.
  • Bei der Anwendungsserver-Komponente 606 kann es sich um eine Anwendung, ein Modul oder eine Komponente handeln, die von dem Anwendungsserver 604 verwendet werden. In einer Ausführungsform kann der Anwendungsserver 606 zum Beispiel eine Kombination aus dem Identitätsnachweismodul 406 in 4 und bestimmten anderen vorhandenen Komponenten einer aktuell verfügbaren Anwendungsserver-Anwendung darstellen. Bei der Anwendungsserver-Komponente 606 kann es sich um mehr als eine Anwendungsserver-Komponente handeln, die unterschiedlichen Funktionen dienen.
  • In einer beispielhaften Ausführungsform kann der Anwendungsserver 604 der Client-Anwendung 602 einen Anmeldedialog 607 anzeigen. Der Anmeldedialog 607 kann optional sein, und die Client-Anwendung 602 kann auf eigene Initiative oder als Reaktion auf den Anmeldedialog 607 Benutzeridentitätsnachweise in der Anforderung 608 bereitstellen. Benutzeridentitätsnachweise können eine Kombination aus einer der Client-Anwendung 602 zugehörigen Anwendungskennung, einer der Client-Anwendung 602 zugehörigen Anwendungsversion, einer der Anforderung 608 zugehörigen Kennung und, falls zutreffend, einer oder mehrerer einem Benutzer oder Konto zugehöriger Benutzeridentitätsnachweise enthalten.
  • Der Anwendungsserver 604 verwendet die Benutzeridentitätsnachweise in der Anforderung 608 zum Überprüfen der Sitzung mit der Client-Anwendung 602 auf Gültigkeit. In einer Ausführungsform kann der Anwendungsserver 604 die Nachricht 610 zur Überprüfung der Gültigkeit der Sitzung an die Anwendungsserver-Komponente 606 senden und zum Vollenden dieser Gültigkeitsprüfung eine Gültigkeitsprüfungsnachricht zurück erhalten.
  • Der Anwendungsserver 604 kann die Anwendungsserver-Komponente 606 zum Erzeugen der Dienstregistrierdatenbank 612 verwenden. Die in Schritt 612 erzeugte Dienstregistrierdatenbank kann als Registrierdatenbank 408 in 4 genutzt werden und kann eine Beschreibung von Diensten sowie Daten oder von anderen über den Anwendungsserver 604 verfügbare Ressourcen enthalten.
  • Die Anwendungsserver-Komponente 606 erzeugt die Dienstkennung 614. Die in Schritt 614 erzeugte Dienstkennung kann als Dienstkennung 410 in 4 und als Dienstkennung 508 in 5 verwendet werden.
  • Der Anwendungsserver 604 sendet eine Antwort 616 an die Client-Anwendung 602. Eine oder mehrere Nachrichten bilden die Antwort 616. Die Antwort 616 überträgt die Dienstkennung und einen Katalog an die Client-Anwendung 602. Bei dem Katalog in der Antwort 616 kann es sich um eine Teilmenge der in Schritt 612 erzeugten Dienstregistrierdatenbank handeln. Der Katalog in der Antwort 616 kann als Katalog 412 in 4 und als Katalog 510 in 5 verwendet werden.
  • Die Client-Anwendung 602 kann eine oder mehrere Unteranforderungen an den Anwendungsserver 604 senden. Die Unteranforderung nach einem Dienst oder Daten 618 ist eine derartige Unteranforderung.
  • Die Client-Anwendung 602 baut die Unteranforderung 618 unter Verwendung der Dienstkennung und des Katalogs, die in Antwort 616 empfangen wurden, dynamisch auf. In einer Ausführungsform kann die Unteranforderung 618 zum Beispiel eine Anforderung nach lediglich dem Dienst enthalten, der in dem in Antwort 616 empfangenen Katalog auftritt. In einer Ausführungsform kann die Unteranforderung 618 ferner die Anwendungskennung der Client-Anwendung 602, die Anwendungsversion der Client-Anwendung 602, die in der Antwort 616 empfangene Dienstkennung oder eine Umwandlung einer derartigen Dienstkennung enthalten.
  • Folglich sichert eine Ausführungsform der Erfindung, anders als die gegenwärtig verwendeten Techniken für asynchrone Client-Server-Transaktionen, die asynchrone Client-Server-Transaktion durch bedarfsweises Erstellen von Unteranforderungen unter Verwendung von Informationen aus dem Katalog und der Dienstkennung, die sich jeweils im Laufe der Zeit ändern können. Durch das Erstellen der Unteranforderung auf diese Weise wird die Unteranforderung dynamisch und widerstandsfähig gegen Fälschungen oder Angriffe durch systematisches Probieren (trial-and-error attacks) durch bösartige Anwendungen.
  • Der Anwendungsserver 604 führt eine Fälligkeitsprüfung der Dienstkennung durch 620, zum Beispiel durch Verwendung der Anwendungsserver-Komponente 606. Eine Ausführungsform kann die Überprüfung 620 nach jeder Unteranforderung 618 durchführen. Eine andere Ausführungsform kann die Überprüfung 620 nach mehreren Unteranforderungen gemäß einer Richtlinie oder einem Algorithmus nach Wahl durchführen.
  • Die auf Zeit beruhende Fälligkeit der Dienstkennung wird in dieser Ausführungsform lediglich als Beispiel verwendet und schränkt die Erfindung nicht ein. Im Rahmen des Schutzumfangs der Erfindung kann in Schritt 620 jedes beliebige sich auf die Dienstkennung beziehende Sicherheitsmerkmal auf geeignete Weise überprüft werden.
  • Wenn die Dienstkennung nicht abgelaufen ist, kann der Anwendungsserver die Anforderung 622 nach dem/den in der Unteranforderung 618 angeforderten Dienst bzw. Daten an die Anwendungsserver-Komponente 606 senden. Der Anwendungsserver 604 kann eine weitere Anforderung 624 nach jeder beliebigen zusätzlichen Datenverarbeitung, die möglicherweise durchgeführt werden muss, unter Verwendung einer Kombination aus der Dienstkennung, der Anwendungskennung und der Anwendungsversion an die Anwendungsserver-Komponente 606 senden. Die Anforderung 624 kann zum Beispiel das Protokollieren der Unteranforderung 618 beantragen. Als weiteres Beispiel kann die Anforderung 624 das Erhöhen eines Fälligkeitszählers der Dienstkennung um eine Einheit beantragen.
  • Der Anwendungsserver 604 sammelt 626 die Daten bzw. den Dienst, die von der Client-Anwendung 602 angefordert wurden. Der Anwendungsserver 604 sendet 628 die Daten bzw. den Dienst an die Client-Anwendung 602.
  • Einige Schritte des Zeitablaufdiagramms aus 6 können in einer auf diese Weise durch eine Ausführungsform gesicherten asynchronen Client-Server-Transaktion öfter als ein Mal auftreten. Der Anwendungsserver 604 kann zum Beispiel eine weitere Antwort 616 senden, darunter eine erneuerte Dienstkennung, einen aktualisierten Katalog oder beides, wenn die Überprüfung 620 erkennt, dass die Dienstkennung in der Unteranforderung 618 abgelaufen ist.
  • Als an der Anwendungsserver-Komponente 606 durchgeführt abgebildete Aktivitäten sind lediglich der Klarheit der Beschreibung halber derart abgebildet. Derartige Aktivitäten können im Rahmen des Schutzumfangs der Erfindung an dem Anwendungsserver 604 oder an einer oder mehreren Anwendungsserver-Komponenten 606 durchgeführt werden.
  • 7 zeigt ein Blockschaltbild eines Prozesses zum Erneuern einer Dienstkennung und eines Katalogs gemäß einer veranschaulichenden Ausführungsform. Die Client-Anwendung 702 kann gleichartig wie die Client-Anwendung 602 in 6 sein. Der Anwendungsserver 704 kann gleichartig wie der Anwendungsserver 604 in 6 sein. Die Anwendungsserver-Komponente 706 kann gleichartig wie die Anwendungsserver-Komponente 606 in 6 sein.
  • In einer beispielhaften Ausführungsform gemäß 7 sendet die Client-Anwendung 702 die anfängliche Anforderung 708 an den Anwendungsserver 704. Die Anwendungsserver-Komponente 706 erzeugt eine Registrierdatenbank und eine Dienstkennung. Der Anwendungsserver 704 sendet einen auf der Registrierdatenbank beruhenden Katalog und die Dienstkennung zurück an die Client-Anwendung 702.
  • Die Client-Anwendung 702 baut unter Verwendung des Katalogs und der Dienstkennung sowie anderer der Client-Anwendung 702 zugehöriger Informationen und der asynchronen Client-Server-Transaktion Unteranforderungen dynamisch auf. Die Client-Anwendung 702 sendet eine oder mehrere derartige dynamisch aufgebaute Unteranforderungen zur Unterstützung der asynchronen Client-Server-Transaktion.
  • Zu einem gewissen Zeitpunkt läuft die Dienstkennung in der Client-Anwendung 702 ab oder wird anderweitig ungültig. Die Dienstkennung kann zum Beispiel ablaufen, bevor die asynchrone Client-Server-Transaktion abgeschlossen wurde, und die Verwendung mehrerer Dienstkennungen zum Abschließen der asynchronen Client-Server-Transaktion erzwingen. Als weiteres Beispiel kann die Dienstkennung zu einer bestimmten Zeit ablaufen, unabhängig davon, ob die Client-Server-Transaktion abgeschlossen wurde.
  • Der Anwendungsserver 704 kann die Gültigkeit der Dienstkennung und anderer Benutzeridentitätsnachweise in jeder beliebigen für eine Umsetzung geeigneten Kombination und auf jede beliebige für eine Umsetzung geeignete Weise prüfen. In einer Ausführungsform kann die Anwendungsserver-Komponente 706 die Dienstkennung in jeder Unteranforderung auf Gültigkeit prüfen. In einer anderen Ausführungsform kann die Dienstkennung in vorgegebenen Intervallen auf Gültigkeit überprüft werden. In einer anderen Ausführungsform kann die Dienstkennung gemeinsam mit anderen Benutzeridentitätsnachweisen auf Gültigkeit überprüft werden.
  • Die Überprüfung der Gültigkeit der Dienstkennung kann jede beliebige für eine Umsetzung geeignete Gültigkeitsprüfung umfassen. Eine Gültigkeitsprüfung kann zum Beispiel die Unversehrtheit der Dienstkennung prüfen, um zu ermitteln, ob die Dienstkennung abgeändert wurde. Eine weitere beispielhafte Gültigkeitsprüfung kann einfach die Fälligkeit der Dienstkennung prüfen. Eine weitere beispielhafte Gültigkeitsprüfung kann eine Prüfung durchführen, um zu ermitteln, ob eine anderweitig gültige Dienstkennung mit derselben Anwendungskennung, mit der die Dienstkennung bei Ausgabe in Beziehung gesetzt wurde, oder mit einer anderen Anwendungskennung verwendet wird.
  • In einer Ausführungsform sendet die Client-Anwendung 702 eine dynamisch aufgebaute Unteranforderung mit einer abgelaufenen Dienstanforderung. Die Gültigkeitsprüfung der abgelaufenen Dienstkennung an der Anwendungsserver-Komponente 706 schlägt fehl. Der Anwendungsserver 704 sendet eine neue oder erneuerte Dienstkennung an die Client-Anwendung 702, wenn eine derartige Erneuerung gewährt wird. Der Anwendungsserver 704 kann zum Beispiel keine erneuerte Dienstkennung senden, wenn die Client-Anwendung 702 zum Ausführen einer asynchronen Client-Server-Transaktion länger als eine vorbestimmte Zeitspanne benötigt hat. Der Katalog an der Client-Anwendung 702 kann auf gleichartige Weise ablaufen, veralten oder anderweitig ungültig werden. Der Anwendungsserver 740 kann den Katalog auf gleichartige Weise erneuern oder aktualisieren, falls dies gewährt wird.
  • Die Client-Anwendung 702 baut nachfolgende Unteranforderungen unter Verwendung der erneuerten Dienstkennung, des erneuerten Katalogs bzw. beider dynamisch auf. Die Nachrichtenübermittlung und der Datenaustausch zwischen der Client-Anwendung 702 und dem Anwendungsserver 704 können auf diese Weise fortgeführt werden, bis die gesicherte asynchrone Client-Server-Transaktion abgeschlossen wurde.
  • 8 zeigt einen Ablaufplan eines Prozesses zum Erzeugen einer Registrierdatenbank, einer Dienstkennung und eines Katalogs gemäß einer veranschaulichenden Ausführungsform. Der Prozess 800 kann in einer Server-Anwendung wie in einer Kombination aus dem Anwendungsserver 704 und der Anwendungsserver-Komponente 706 in 7 umgesetzt werden.
  • Der Prozess 800 beginnt mit dem Empfangen einer Anforderung (Schritt 802). Die Anforderung in Schritt 802 kann eine anfängliche Anforderung sein, die einfach eine Anwendung kennzeichnet, oder es kann eine Anforderung nach einem Dienst oder Daten sein.
  • Der Prozess 800 erkennt eine Anwendungskennung und eine Anwendungsversion in der Anforderung aus Schritt 802 (Schritt 804). Wenn der Prozess 800 ermittelt, dass die Verbindungsmöglichkeiten mit dem Sender der Anforderung annehmbar sind (nicht gezeigt), erzeugt der Prozess 800 eine Dienstkennung (Schritt 806).
  • Der Prozess 800 erzeugt ebenfalls eine Registrierdatenbank mit Diensten, Daten oder einer Kombination daraus, die der Sender der Anforderung möglicherweise nutzen darf (Schritt 808). Der Prozess 800 aktualisiert die Registrierdatenbank mit der Dienstkennung und allen anderen Benutzeridentitätsnachweisen aus der Anforderung (Schritt 810).
  • Der Prozess 800 erzeugt auf Grundlage der Registrierdatenbank einen Katalog mit Diensten und Daten (Schritt 812). Der Prozess 800 sendet die Dienstkennung und den Katalog als Reaktion auf die Anforderung aus Schritt 802 (Schritt 814). Danach endet der Prozess 800.
  • 9 zeigt einen Ablaufplan eines Prozesses zum Sichern von asynchronen Client-Server-Transaktionen gemäß einer veranschaulichenden Ausführungsform. Der Prozess 900 kann in einer Server-Anwendung wie dem Anwendungsserver 704 oder der Anwendungsserver-Komponente 706 in 7 oder einer Kombination daraus umgesetzt werden.
  • Der Prozess 900 beginnt mit dem Empfangen einer Anforderung, die eine Kombination aus einer Anwendungskennung, einer Anwendungsversion und einer Dienstkennung enthält (Schritt 902). Die Anforderung aus Schritt 902 kann gleichartig wie eine Unteranforderung aus 7 sein. Die Dienstkennung kann gleichartig wie die in Schritt 814 in 8 gesendete Dienstkennung sein.
  • Der Prozess 900 ermittelt, ob die Dienstkennung abgelaufen oder andernfalls gültig ist, ob der Katalog bei dem Sender der Anforderung aktualisiert werden muss oder beides (Schritt 904). Wenn der Prozess 900 ermittelt, dass die Dienstkennung abgelaufen oder der Katalog bei dem Sender veraltet ist („JA”-Pfad aus Schritt 904), ermittelt der Prozess 900, ob die Dienstkennung, der Katalog oder beides zu erneuern ist (Schritt 906).
  • Wenn der Prozess 900 ermittelt, dass die Dienstkennung, der Katalog oder beides nicht zu erneuern sind („NEIN”-Pfad aus Schritt 906), kann der Prozess 900 die Anforderung protokollieren (Schritt 908). Der Prozess 900 kann auch eine Fehlermeldung an den Sender der Anforderung senden (Schritt 910). Danach endet der Prozess 900.
  • Wenn der Prozess 900 ermittelt, dass die Dienstkennung, der Katalog oder beides zu erneuern sind („JA”-Pfad aus Schritt 906), kann der Prozess 900 eine neue Dienstkennung erzeugen oder die Fälligkeitsfrist der bestehenden Dienstkennung verlängern (Schritt 912). Falls benötigt, kann der Prozess 900 auch einen neuen Katalog erzeugen, eine Aktualisierung des bestehenden Katalogs erzeugen oder die Gültigkeit des bestehenden Katalogs verlängern (Schritt 914). Der Prozess 900 sendet die neue bzw. erneuerte Dienstkennung, den neuen bzw. erneuerten Katalog oder beides nach Bedarf als Reaktion auf die Anforderung aus Schritt 902 (Schritt 916). Danach endet der Prozess 900.
  • Wenn der Prozess 900 in Schritt 904 ermittelt, dass die Dienstkennung gültig und der Katalog aktuell ist („NEIN”-Pfad aus Schritt 904), ermittelt der Prozess 900, ob die Sitzung mit dem Sender der Anforderung gültig ist (Schritt 918). Wenn der Prozess 900 ermittelt, dass die Sitzung mit dem Sender der Anforderung ungültig ist, zum Beispiel wenn die Dienstkennung oder deren Verwendung ungültig ist oder eine Anforderung einen nicht in dem Katalog enthaltenen Dienst anfordert („NEIN”-Pfad aus Schritt 912), fährt der Prozess 900 mit Schritt 908 fort. Ob sich ein angeforderter Dienst in dem Katalog befindet, kann zum Beispiel durch Untersuchen des Teils der in dem Katalog enthaltenen Registrierdatenbank ermittelt werden.
  • Wenn der Prozess 900 ermittelt, dass die Sitzung mit dem Sender der Anforderung gültig ist („JA”-Pfad aus Schritt 918), ermittelt der Prozess 900, ob der angeforderte Dienst bzw. die angeforderten Daten einen zusätzlichen Identitätsnachweis benötigen (Schritt 920). Bestimmte Dienste können zum Beispiel ihre eigene Anmeldekennung und ihr eigenes Kennwort erfordern.
  • Wenn der Prozess 900 ermittelt, dass ein zusätzlicher Identitätsnachweis benötigt wird („JA”-Pfad aus Schritt 920), sendet der Prozess 900 zusätzliche Identitätsnachweisnachrichten, zum Beispiel durch Anzeigen eines Anmeldedialogfensters auf einer Anzeige (Schritt 922). Der Prozess 900 empfängt zusätzliche Identitätsnachweisdaten (Schritt 924).
  • Der Prozess 900 ermittelt, ob die zusätzlichen Identitätsnachweisdaten gültig sind (Schritt 926). Wenn die zusätzlichen Identitätsnachweisdaten nicht gültig sind („NEIN”-Pfad aus Schritt 926), fährt der Prozess 900 mit Schritt 908 fort.
  • Wenn die zusätzlichen Identitätsnachweisdaten gültig sind („JA”-Pfad aus Schritt 926) oder wenn der angeforderte Dienst keine zusätzlichen Identitätsnachweisdaten benötigt („NEIN”-Pfad aus Schritt 920), stellt der Prozess 900 den angeforderten Dienst bzw. die angeforderten Daten bereit (Schritt 928). Der Prozess 900 sendet das Ergebnis des durchgeführten Dienstes bzw. die gemäß der Anforderung bearbeiteten Daten (Schritt 930). Danach endet der Prozess 900. Die Ergebnisse können an den Sender der Anforderung oder an eine andere Anwendung bzw. Einheit gesendet werden, ohne von dem Umfang der Erfindung abzuweichen.
  • 10 zeigt einen Ablaufplan eines weiteren Prozesses zum Sichern von asynchronen Client-Server-Transaktionen gemäß einer veranschaulichenden Ausführungsform. Der Prozess 1000 kann in einer Client-Anwendung wie der Client-Anwendung 702 in 7 umgesetzt werden.
  • Der Prozess 1000 beginnt mit dem Senden einer Anforderung (Schritt 1002). Die Anforderung kann gleichartig wie die in Schritt 802 in Prozess 800 in 8 empfangene Anforderung sein.
  • Wenn die Anforderung gemäß einem (nicht gezeigten) Empfänger der Anforderung gültig ist, empfängt der Prozess 1000 eine Dienstkennung und einen Katalog (Schritt 1004). Der Prozess 1000 baut unter Verwendung der Dienstkennung und des Katalogs eine oder mehrere Unteranforderungen nach einem Dienst oder Daten auf (Schritt 1006). Der Prozess 1000 kann in den Unteranforderungen auch zusätzliche Benutzeridentitätsnachweise enthalten.
  • Der Prozess 1000 sendet die dynamisch erstellte Unteranforderung (Schritt 1008). Als Reaktion auf die Unteranforderung aus Schritt 1008 kann der Prozess 1000 eine Kombination aus einem angeforderten Dienst bzw. angeforderten Daten (Schritt 1010), einer erneuerten Dienstkennung bzw. einem erneuerten Katalog (Schritt 1012) und einer Fehlermeldung (Schritt 1014) empfangen. Danach endet der Prozess 1000.
  • Die oben beschriebenen Komponenten in den Blockschaltbildern und Schritte in den Ablaufplänen sind lediglich als Beispiele beschrieben. Die Komponenten und Schritte wurden der Klarheit der Beschreibung halber ausgewählt und schränken die veranschaulichenden Ausführungsformen der Erfindung nicht ein. Eine bestimmte Ausführung kann zum Beispiel jede beliebige der Komponenten bzw. jeden beliebigen der Schritte verknüpfen, weglassen, weiter unterteilen, abändern, erweitern, verringern oder alternativ umsetzen, ohne von dem Umfang der veranschaulichenden Ausführungsformen abzuweichen. Des Weiteren können die Schritte der oben beschriebenen Prozesse innerhalb des Umfangs der Erfindung in einer unterschiedlichen Reihenfolge durchgeführt werden.
  • Somit werden in den veranschaulichenden Ausführungsformen ein computerimplementiertes Verfahren, eine Vorrichtung und ein Computerprogrammprodukt zum Sichern von asynchronen Client-Server-Transaktionen bereitgestellt. Unter Verwendung der Ausführungsformen der Erfindung können asynchrone Client-Server-Transaktionen auf eine Weise gesichert werden, dass während einer asynchronen Client-Server-Transaktion nicht auf in keinem Zusammenhang dazu stehende Dienste zugegriffen werden kann. Ein Anforderer einer asynchronen Client-Server-Transaktion ist auf bestimmte Dienste und Daten beschränkt, die von dem Anbieter als zulässig ermittelt wurden.
  • Die Erfindung ermöglicht es dem Anforderer der asynchronen Client-Server-Transaktion ferner, Anforderungen innerhalb der asynchronen Client-Server-Transaktion unter Verwendung von durch den Anbieter gelieferten Informationen dynamisch aufzubauen. Die Kombination aus den eigenen Informationen des Anforderers, den von einem Anbieter gelieferten Informationen und der Beschränkung, welcher Dienst und welche Daten angefordert werden dürfen, sichert die asynchrone Client-Server-Transaktion gemäß den Ausführungsformen der Erfindung. Die Art der Dienstkennung, die Kombination aus der Dienstkennung mit anderen Kennungen und die Fälligkeit und Erneuerung der Dienstkennung gemäß den Ausführungsformen verleihen der asynchronen Client-Server-Transaktion eine Widerstandsfähigkeit gegen Fälschungen oder Angriffe durch systematisches Probieren (Trial-and-Error).
  • Die Ausführungsformen der Erfindung stellen flexible Sicherheitskonfigurationen bereit, die nach Bedarf geändert bzw. aktualisiert werden können. Die Ausführungsformen der Erfindung stellen ferner einen Sicherheitsmechanismus bereit, der keine zusätzliche Hardware benötigt und in bestehenden Hardware-Software-Konfigurationen der meisten bestehenden Datenverarbeitungssysteme betrieben werden kann.
  • Die Ausführungsformen der Erfindung können auch mit bestehenden Identitätsnachweisanwendungen und -komponenten zusammenarbeiten. Die Ausführungsformen können ebenfalls mit bestehenden Richtlinieninfrastrukturen zusammenarbeiten, die ggf. in bestimmten Datenverarbeitungsumgebungen verwendet werden.
  • Die Erfindung kann als vollständige Software-Ausführungsform oder als Ausführungsform, die sowohl Hardware- als auch Software-Elemente enthält, ausgeführt werden. In einer bevorzugten Ausführungsform ist die Erfindung als Software oder Programmcode realisiert, darunter insbesondere Firmware, im Speicher residente Software, Mikrocode usw.
  • Des Weiteren kann die Erfindung die Form eines Computerprogrammprodukts annehmen, das auf einem durch einen Computer verwendbaren bzw. durch einen Computer lesbaren Medium zum Zugriff bereitsteht, das Programmcode bereitstellt, der von oder in Verbindung mit einem Computer oder jedem beliebigen Anweisungsausführungssystem verwendet werden kann. Für diese Beschreibung kann ein durch einen Computer verwendbares bzw. durch einen Computer lesbares Medium jede beliebige physische Vorrichtung sein, die das Programm, das von oder in Verbindung mit dem Anweisungsausführungssystem, der Vorrichtung oder der Einheit verwendet wird, enthalten, speichern, übertragen, verbreiten bzw. transportieren kann.
  • Bei dem Medium kann es sich um ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitersystem (bzw. Vorrichtung oder Einheit) oder ein Verbreitungsmedium handeln. Zu Beispielen für ein durch einen Computer lesbares Medium zählen ein Halbleiter- oder Festkörperspeicher, Magnetband, eine auswechselbare Computerdiskette, Direktzugriffsspeicher (RAM), Nur-Lese-Speicher (ROM), eine starre Magnetplatte und eine optische Platte. Zu aktuellen Beispielen optischer Platten gehören ein Kompaktspeicherplatte-Nur-Lese-Speicher (CD-ROM), eine Lese-/Schreib-Kompaktspeicherplatte (CD-R/W) und eine DVD.
  • Des Weiteren kann ein Computerspeichermedium einen durch einen Computer lesbaren Programmcode enthalten oder speichern, so dass, wenn der durch einen Computer lesbare Programmcode auf einem Computer ausgeführt wird, das Ausführen dieses durch einen Computer lesbaren Programmcodes den Computer dazu veranlasst, einen anderen durch einen Computer lesbaren Programmcode über eine Datenübertragungsverbindung zu übertragen. Diese Datenübertragungsverbindung kann ein Medium verwenden, das beispielsweise, ohne dass dies eine Einschränkung darstellt, physisch oder drahtlos sein kann.
  • Ein zur Speicherung und/oder Ausführung von Programmcode geeignetes Datenverarbeitungssystem enthält mindestens einen Prozessor, der direkt oder indirekt über einen Systembus mit Speicherelementen verbunden ist. Die Speicherelemente können einen lokalen Speicher aufweisen, der während der eigentlichen Ausführung des Programmcodes eingesetzt wird, Massenspeichermedien sowie Cache-Speicher, die eine vorübergehende Speicherung von zumindest etwas Programmcode bereitstellen, um die Häufigkeit, mit der während der Ausführung Code von den Massenspeichermedien abgerufen werden muss, zu verringern.
  • Ein Datenverarbeitungssystem kann als Server-Datenverarbeitungssystem oder Client-Datenverarbeitungssystem dienen. Server- und Client-Datenverarbeitungssysteme können Datenspeichermedien enthalten, die durch einen Computer verwendbar sind, zum Beispiel durch einen Computer lesbar. Ein einem Server-Datenverarbeitungssystem zugehöriges Datenspeichermedium kann auf einem Computer verwendbaren Code enthalten. Ein Client-Datenverarbeitungssystem kann diesen auf einem Computer verwendbaren Code herunterladen, zum Beispiel zum Speichern auf einem dem Client-Datenverarbeitungssystem zugehörigen Datenspeichermedium oder zur Verwendung in dem Client-Datenverarbeitungssystem. Das Server-Datenverarbeitungssystem kann gleichartig auf einem Computer verwendbaren Code von dem Client-Datenverarbeitungssystem heraufladen. Der sich aus einer Ausführung eines durch einen Computer verwendbaren Programmprodukt der veranschaulichenden Ausführungsformen ergebende, auf einem Computer verwendbare Code kann auf diese Art unter Verwendung des Server- bzw. Client-Datenverarbeitungssystems herauf- oder heruntergeladen werden.
  • Eingabe/Ausgabe- bzw. E/A-Einheiten (darunter Tastaturen, Anzeigen, Zeigegeräte usw., jedoch nicht darauf beschränkt) können entweder direkt oder über mitbeteiligte E/A-Steuereinheiten mit dem System verbunden werden.
  • Es können auch Netzwerkadapter mit dem System verbunden werden, um es dem Datenverarbeitungssystem zu ermöglichen, über mitbeteiligte private oder öffentliche Netzwerke mit anderen Datenverarbeitungssystemen oder entfernt angeordneten Druckern oder Speichervorrichtungen verbunden zu werden. Modems, ein Kabelmodem sowie Ethernet-Karten sind nur einige wenige der momentan verfügbaren Arten von Netzwerkadaptern.
  • Die Beschreibung der vorliegenden Erfindung wurde zum Zwecke der Veranschaulichung und Beschreibung dargelegt und soll nicht als erschöpfend betrachtet werden oder die Erfindung auf die offenbarte Ausführung einschränken. Für Fachleute werden viele Abänderungen und Abweichungen ersichtlich sein. Die Ausführungsform wurde gewählt und beschrieben, um die Grundgedanken der Erfindung und die praktische Anwendung zu erläutern und um es anderen Fachleuten zu ermöglichen, die Erfindung in verschiedenen Ausführungsformen mit verschiedenen Abänderungen, die für eine bestimmte vorgesehene Verwendung geeignet sind, zu verstehen.

Claims (31)

  1. Computerimplementiertes Verfahren zum Sichern von asynchronen Client-Server-Transaktionen, das Folgendes umfasst: Empfangen einer Anforderung an einer ersten in einem Datenverarbeitungssystem ausgeführten Anwendung, wobei die Anforderung eine Anwendungskennung und eine Version, die einer zweiten Anwendung zugehörig sind, enthält; Erzeugen einer Dienstkennung als Reaktion darauf, dass eine Sitzung mit der zweiten Anwendung gültig ist; Erzeugen einer Registrierdatenbank an der ersten Anwendung, wobei die Registrierdatenbank Informationen über eine Reihe von Diensten und Daten enthält, welche die zweite Anwendung verwenden darf; Erzeugen eines Katalogs beruhend auf der Registrierdatenbank, wobei der Katalog eine umgewandelte Teilmenge der Registrierdatenbank enthält; und Senden der Dienstkennung und des Katalogs an die zweite Anwendung.
  2. Computerimplementiertes Verfahren nach Anspruch 1, das ferner Folgendes umfasst: Empfangen einer Unteranforderung, wobei es sich bei der Unteranforderung um einen Teil einer asynchronen Client-Server-Transaktion handelt, wobei die Unteranforderung die Dienstkennung enthält; Ermitteln einer Gültigkeit der Unteranforderung durch Ermitteln einer Kombination aus (i) ob die Dienstkennung abgelaufen ist, (ii) ob die Unteranforderung einen Dienst anfordert, der gemäß dem Katalog zulässig ist, und (iii) ob die Dienstkennung in Verbindung mit der zweiten Anwendung verwendet wird; und Bereitstellen des Dienstes als Reaktion auf die Unteranforderung, sofern die Unteranforderung gültig ist.
  3. Computerimplementiertes Verfahren nach Anspruch 2, bei dem das Ermitteln der Gültigkeit in der Kombination ferner (iv) das Ermitteln verwendet, ob der Katalog veraltet ist.
  4. Computerimplementiertes Verfahren nach Anspruch 2, bei dem das Ermitteln, ob die Dienstkennung in Verbindung mit der zweiten Anwendung verwendet wird, das Ermitteln, ob die Dienstkennung gemeinsam mit der Anwendungskennung und der Anwendungsversion der zweiten Anwendung verwendet wird, umfasst.
  5. Computerimplementiertes Verfahren nach Anspruch 2, das ferner Folgendes umfasst: Bereitstellen entweder (i) einer erneuerten Dienstkennung oder (ii) eines erneuerten Katalogs, sofern die Unteranforderung ungültig ist.
  6. Computerimplementiertes Verfahren nach Anspruch 5, bei dem es sich bei der erneuerten Dienstkennung entweder (i) um eine neue Dienstkennung handelt, (ii) die Dienstkennung ein abgeändertes Sicherheitsmerkmal enthält oder (iii) die Dienstkennung einer Abänderung des Kriteriums zum Prüfen der Gültigkeit des Sicherheitsmerkmals in der ersten Anwendung entspricht, und bei dem das Bereitstellen stattfindet, bevor die asynchrone Client-Server-Transaktion abgeschlossen ist.
  7. Computerimplementiertes Verfahren nach Anspruch 5, bei dem es sich bei dem erneuerten Katalog entweder (i) um einen neuen Katalog, (ii) eine Aktualisierung des Katalogs oder (iii) eine Abänderung eines Fälligkeitsparameters des Katalogs handelt, und bei dem das Bereitstellen stattfindet, bevor die asynchrone Client-Server-Transaktion abgeschlossen ist.
  8. Computerimplementiertes Verfahren nach Anspruch 2, das ferner Folgendes umfasst: Ermitteln, ob der Dienst einen zusätzlichen Identitätsnachweis benötigt, wobei eine Feststellung eines zusätzlichen Identitätsnachweises gebildet wird; als Reaktion darauf, dass die Feststellung eines zusätzlichen Identitätsnachweis wahr ist, Empfangen von zusätzlichen Identitätsnachweisdaten; und Ermitteln, ob die zusätzlichen Identitätsnachweisdaten gültig sind, wobei der Dienst als Reaktion darauf bereitgestellt wird, dass die zusätzlichen Identitätsnachweisdaten gültig sind.
  9. Computerimplementiertes Verfahren nach Anspruch 2, bei dem das Ermitteln, ob der Dienst gemäß dem Katalog zulässig ist, durchgeführt wird, indem unter Verwendung der Registrierdatenbank ermittelt wird, ob der Dienst zulässig ist.
  10. Computerimplementiertes Verfahren nach Anspruch 1, das ferner Folgendes umfasst: Erzeugen einer anfänglichen Dienstkennung, wobei es sich bei der Dienstkennung um eine umgewandelte Version der anfänglichen Dienstkennung handelt.
  11. Computerimplementiertes Verfahren zum Sichern von asynchronen Client-Server-Transaktionen, wobei das auf einem Computer ausgeführte Verfahren Folgendes umfasst: Empfangen einer Sicherheitskennung und eines Katalogs von einer ersten Anwendung an einer zweiten in einem Datenverarbeitungssystem ausgeführten Anwendung als Reaktion auf das Senden einer Anwendungskennung und einer Anwendungsversion, die der zweiten Anwendung zugehörig sind, wobei der Katalog eine umgewandelte Teilmenge einer der ersten Anwendung zugehörigen Registrierdatenbank enthält; dynamisches Aufbauen einer Unteranforderung, wobei es sich bei der Unteranforderung um einen Teil einer asynchronen Client-Server-Transaktion handelt, wobei die Unteranforderung die Dienstkennung enthält und die Unteranforderung ferner eine Anforderung nach einem Dienst aus dem Katalog enthält; Empfangen von dem Dienst zugehörigen Daten, sofern die Unteranforderung gemäß der ersten Anwendung gültig ist.
  12. Computerimplementiertes Verfahren nach Anspruch 11, bei dem die Unteranforderung ferner die Anwendungskennung und die Anwendungsversion, die der zweiten Anwendung zugehörig sind, enthält.
  13. Computerimplementiertes Verfahren nach Anspruch 11 oder Anspruch 12, das ferner Folgendes umfasst: sofern die Unteranforderung ungültig ist, Empfangen entweder (i) einer erneuerten Dienstkennung oder (ii) eines erneuerten Katalogs, wobei die Unteranforderung auf Grund der Feststellung, dass entweder (i) die Dienstkennung ungültig ist, (ii) der Dienst nicht in dem Katalog enthalten ist oder (iii) der Katalog veraltet ist, ungültig ist; und dynamisches Aufbauen einer zweiten Unteranforderung unter Verwendung entweder (i) der erneuerten Dienstkennung oder (ii) des erneuerten Katalogs.
  14. Auf einem Computer verwendbares Programmprodukt, das ein in einem Computer verwendbares Speichermedium umfasst, das einen auf einem Computer verwendbaren Code zum Sichern von asynchronen Client-Server-Transaktionen enthält, wobei der auf einem Computer verwendbare Code Folgendes umfasst: auf einem Computer verwendbaren Code zum Empfangen einer Anforderung an einer ersten in einem Datenverarbeitungssystem ausgeführten Anwendung, wobei die Anforderung eine Anwendungskennung und eine Version enthält, die einer zweiten Anwendung zugehörig sind; auf einem Computer verwendbaren Code zum Erzeugen einer Dienstkennung als Reaktion darauf, dass eine Sitzung mit der zweiten Anwendung gültig ist; auf einem Computer verwendbaren Code zum Erzeugen einer Registrierdatenbank an der ersten Anwendung, wobei die Registrierdatenbank Informationen über eine Reihe von Diensten und Daten enthält, welche die zweite Anwendung verwenden darf; auf einem Computer verwendbaren Code zum Erzeugen eines Katalogs beruhend auf der Registrierdatenbank, wobei der Katalog eine umgewandelte Teilmenge der Registrierdatenbank enthält; und auf einem Computer verwendbaren Code zum Senden der Dienstkennung und des Katalogs an die zweite Anwendung.
  15. Auf einem Computer verwendbares Programmprodukt nach Anspruch 14, das ferner Folgendes umfasst: auf einem Computer verwendbaren Code zum Empfangen einer Unteranforderung, wobei es sich bei der Unteranforderung um einen Teil einer asynchronen Client-Server-Transaktion handelt, wobei die Unteranforderung die Dienstkennung enthält; auf einem Computer verwendbaren Code zum Ermitteln einer Gültigkeit der Unteranforderung durch Ermitteln einer Kombination aus (i) ob die Dienstkennung abgelaufen ist, (ii) ob die Unteranforderung einen Dienst anfordert, der gemäß dem Katalog zulässig ist, und (iii) ob die Dienstkennung in Verbindung mit der zweiten Anwendung verwendet wird; und auf einem Computer verwendbaren Code zum Bereitstellen des Dienstes als Reaktion auf die Unteranforderung, sofern die Unteranforderung gültig ist.
  16. Auf einem Computer verwendbares Programmprodukt nach Anspruch 15, bei dem das Ermitteln der Gültigkeit in der Kombination ferner (iv) das Ermitteln verwendet, ob der Katalog veraltet ist.
  17. Auf einem Computer verwendbares Programmprodukt nach Anspruch 15, bei dem das Ermitteln, ob die Dienstkennung in Verbindung mit der zweiten Anwendung verwendet wird, das Ermitteln, ob die Dienstkennung gemeinsam mit der Anwendungskennung und der Anwendungsversion der zweiten Anwendung verwendet wird, umfasst.
  18. Auf einem Computer verwendbares Programmprodukt nach Anspruch 15, das ferner Folgendes umfasst: auf einem Computer verwendbaren Code zum Bereitstellen entweder (i) einer erneuerten Dienstkennung oder (ii) eines erneuerten Katalogs, sofern die Unteranforderung ungültig ist.
  19. Auf einem Computer verwendbares Programmprodukt nach Anspruch 18, bei dem es sich bei der erneuerten Dienstkennung entweder (i) um eine neue Dienstkennung handelt, (ii) die Dienstkennung ein abgeändertes Sicherheitsmerkmal enthält oder (iii) die Dienstkennung einer Abänderung des Kriteriums zum Prüfen der Gültigkeit des Sicherheitsmerkmals in der ersten Anwendung entspricht, und bei dem das Bereitstellen stattfindet, bevor die asynchrone Client-Server-Transaktion abgeschlossen ist.
  20. Auf einem Computer verwendbares Programmprodukt nach Anspruch 18, bei dem es sich bei dem erneuerten Katalog entweder (i) um einen neuen Katalog, (ii) eine Aktualisierung des Katalogs oder (iii) eine Abänderung eines Fälligkeitsparameters des Katalogs handelt, und bei dem das Bereitstellen stattfindet, bevor die asynchrone Client-Server-Transaktion abgeschlossen ist.
  21. Auf einem Computer verwendbares Programmprodukt nach Anspruch 15, das ferner Folgendes umfasst: auf einem Computer verwendbaren Code zum Ermitteln, ob der Dienst einen zusätzlichen Identitätsnachweis benötigt, was eine Ermittlung von zusätzlichem Identitätsnachweisbedarf darstellt; auf einem Computer verwendbaren Code zum Empfangen von zusätzlichen Identitätsnachweisdaten als Reaktion darauf, dass die Ermittlung eines zusätzlichen Identitätsnachweisbedarfes wahr ist; und auf einem Computer verwendbaren Code zum Ermitteln, ob die zusätzlichen Identitätsnachweisdaten gültig sind, wobei der Dienst als Reaktion darauf bereitgestellt wird, dass die zusätzlichen Identitätsnachweisdaten gültig sind.
  22. Auf einem Computer verwendbares Programmprodukt nach Anspruch 15, bei dem das Ermitteln, ob der Dienst gemäß dem Katalog zulässig ist, durchgeführt wird, indem unter Verwendung der Registrierdatenbank ermittelt wird, ob der Dienst zulässig ist.
  23. Auf einem Computer verwendbares Programmprodukt nach Anspruch 14, das ferner Folgendes umfasst: auf einem Computer verwendbaren Code zum Erzeugen einer anfänglichen Dienstkennung, wobei es sich bei der Dienstkennung um eine umgewandelte Version der anfänglichen Dienstkennung handelt.
  24. Auf einem Computer verwendbares Programmprodukt nach Anspruch 14, bei dem der auf einem Computer verwendbare Code in einem durch einen Computer lesbaren Speichermedium in einem Datenverarbeitungssystem gespeichert ist, und bei dem der auf einem Computer verwendbare Code über ein Netzwerk von einem entfernt angeordneten Datenverarbeitungssystem übertragen wird.
  25. Auf einem Computer verwendbares Programmprodukt nach Anspruch 14, bei dem der auf einem Computer verwendbare Code in einem durch einen Computer lesbaren Speichermedium in einem Server-Datenverarbeitungssystem gespeichert ist, und bei dem der auf einem Computer verwendbare Code über ein Netzwerk auf ein entfernt angeordnetes Datenverarbeitungssystem zur Verwendung in einem dem entfernt angeordneten Datenverarbeitungssystem zugehörigen, durch einen Computer lesbaren Speichermedium heruntergeladen wird.
  26. Datenverarbeitungssystem zum Sichern von asynchronen Client-Server-Transaktionen, wobei das Datenverarbeitungssystem Folgendes umfasst: eine Speichereinheit, die ein Speichermedium enthält, wobei auf der Speichereinheit auf einem Computer verwendbarer Programmcode gespeichert ist; und einen Prozessor, wobei der Prozessor den auf einem Computer verwendbaren Programmcode ausführt, und wobei der auf einem Computer verwendbare Programmcode Folgendes umfasst: auf einem Computer verwendbaren Code zum Empfangen einer Sicherheitskennung und eines Katalogs von einer ersten Anwendung an einer zweiten in einem Datenverarbeitungssystem ausgeführten Anwendung als Reaktion auf das Senden einer Anwendungskennung und einer Anwendungsversion, die der zweiten Anwendung zugehörig sind, wobei der Katalog eine umgewandelte Teilmenge einer der ersten Anwendung zugehörigen Registrierdatenbank enthält; auf einem Computer verwendbaren Code zum dynamischen Aufbauen einer Unteranforderung, wobei es sich bei der Unteranforderung um einen Teil einer asynchronen Client-Server-Transaktion handelt, wobei die Unteranforderung die Dienstkennung enthält und die Unteranforderung ferner eine Anforderung nach einem Dienst aus dem Katalog enthält; und auf einem Computer verwendbaren Code zum Empfangen von dem Dienst zugehörigen Daten, sofern die Unteranforderung gemäß der ersten Anwendung gültig ist.
  27. Datenverarbeitungssystem nach Anspruch 26, bei dem die Unteranforderung ferner die Anwendungskennung und die Anwendungsversion enthält, die der zweiten Anwendung zugehörig sind.
  28. Datenverarbeitungssystem nach Anspruch 26, das ferner Folgendes umfasst: auf einem Computer verwendbaren Code zum Empfangen entweder (i) einer erneuerten Dienstkennung oder (ii) eines erneuerten Katalogs, sofern die Unteranforderung ungültig ist, wobei die Unteranforderung auf Grund der Feststellung, dass entweder (i) die Dienstkennung ungültig ist, (ii) der Dienst nicht in dem Katalog enthalten ist oder (iii) der Katalog veraltet ist, ungültig ist; und auf einem Computer verwendbaren Code zum dynamischen Aufbauen einer zweiten Unteranforderung unter Verwendung entweder (i) der erneuerten Dienstkennung oder (ii) des erneuerten Katalogs.
  29. Datenverarbeitungssystem zum Sichern von asynchronen Client-Server-Transaktionen, wobei das Datenverarbeitungssystem Folgendes umfasst: ein Mittel zum Empfangen einer Anforderung an einer ersten in einem Datenverarbeitungssystem ausgeführten Anwendung, wobei die Anforderung eine Anwendungskennung und eine Version, die einer zweiten Anwendung zugehörig sind, enthält; ein Mittel zum Erzeugen einer Dienstkennung als Reaktion darauf, dass eine Sitzung mit der zweiten Anwendung gültig ist; ein Mittel zum Erzeugen einer Registrierdatenbank an der ersten Anwendung, wobei die Registrierdatenbank Informationen über eine Reihe von Diensten und Daten enthält, welche die zweite Anwendung verwenden darf; ein Mittel zum Erzeugen eines Katalogs beruhend auf der Registrierdatenbank, wobei der Katalog eine umgewandelte Teilmenge der Registrierdatenbank enthält; und ein Mittel zum Senden der Dienstkennung und des Katalogs an die zweite Anwendung.
  30. Datenverarbeitungssystem nach Anspruch 29, das ferner Folgendes umfasst: ein Mittel zum Empfangen einer Unteranforderung, wobei es sich bei der Unteranforderung um einen Teil einer asynchronen Client-Server-Transaktion handelt, wobei die Unteranforderung die Dienstkennung enthält; ein Mittel zum Ermitteln einer Gültigkeit der Unteranforderung durch Ermitteln einer Kombination aus (i) ob die Dienstkennung abgelaufen ist, (ii) ob die Unteranforderung einen Dienst anfordert, der gemäß dem Katalog zulässig ist, und (iii) ob die Dienstkennung in Verbindung mit der zweiten Anwendung verwendet wird; ein Mittel zum Bereitstellen des Dienstes als Reaktion auf die Unteranforderung, sofern die Unteranforderung gültig ist.
  31. Computerprogramm, das ein Programmcodemittel umfasst, das dafür geeignet ist, alle Schritte nach den Ansprüchen 1 bis 13 durchzuführen, wenn das Programm auf einem Computer ausgeführt wird.
DE112010004135.0T 2009-12-15 2010-12-13 Sicherung Asynchroner Client-Server-Transaktionen Active DE112010004135B4 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US12/638,176 US8479268B2 (en) 2009-12-15 2009-12-15 Securing asynchronous client server transactions
US12/638,176 2009-12-15
PCT/EP2010/069479 WO2011073125A1 (en) 2009-12-15 2010-12-13 Securing asynchronous client server transactions

Publications (2)

Publication Number Publication Date
DE112010004135T5 true DE112010004135T5 (de) 2012-09-13
DE112010004135B4 DE112010004135B4 (de) 2019-07-11

Family

ID=43706318

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112010004135.0T Active DE112010004135B4 (de) 2009-12-15 2010-12-13 Sicherung Asynchroner Client-Server-Transaktionen

Country Status (7)

Country Link
US (4) US8479268B2 (de)
JP (1) JP5613259B2 (de)
CN (1) CN102771101B (de)
DE (1) DE112010004135B4 (de)
GB (1) GB2489164A (de)
TW (1) TWI505681B (de)
WO (1) WO2011073125A1 (de)

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9590990B2 (en) * 2009-05-11 2017-03-07 International Business Machines Corporation Assigning user requests of different types or protocols to a user by trust association interceptors
US8479268B2 (en) * 2009-12-15 2013-07-02 International Business Machines Corporation Securing asynchronous client server transactions
US8327005B2 (en) * 2011-02-24 2012-12-04 Jibe Mobile Method to set up application to application communication over a network between applications running on endpoint devices
CN102907062B (zh) * 2011-05-26 2016-06-22 华为技术有限公司 获取云服务的方法和终端、云输入方法和设备、云服务卡及系统
US9443258B2 (en) 2011-08-26 2016-09-13 Apple Inc. Mass ingestion of content related metadata to an online content portal
US9122870B2 (en) 2011-09-21 2015-09-01 SunStone Information Defense Inc. Methods and apparatus for validating communications in an open architecture system
US20130091266A1 (en) 2011-10-05 2013-04-11 Ajit Bhave System for organizing and fast searching of massive amounts of data
US9027108B2 (en) * 2012-05-23 2015-05-05 Box, Inc. Systems and methods for secure file portability between mobile applications on a mobile device
KR102002901B1 (ko) * 2013-01-28 2019-07-23 삼성전자 주식회사 메모리 장치, 메모리 시스템 및 이의 제어 방법
US9219758B2 (en) 2013-03-05 2015-12-22 Qualcomm Incorporated Renewing registrations for a plurality of client applications that are associated with the same host server via an implicit piggybacking scheme
US9858321B2 (en) * 2013-09-20 2018-01-02 Oracle International Corporation Accessing application services from forms
US9462044B1 (en) * 2013-11-25 2016-10-04 Ca, Inc. Secure user, device, application registration protocol
US8863158B1 (en) * 2013-12-04 2014-10-14 Google Inc. Intents with application-specific data
WO2015106249A1 (en) * 2014-01-13 2015-07-16 Futurewei Technologies, Inc. Packet labeling in a virtual network
US9756030B2 (en) * 2014-08-08 2017-09-05 Eurotech S.P.A. Secure cloud based multi-tier provisioning
CN105635083A (zh) * 2014-11-14 2016-06-01 航天信息股份有限公司 基于服务器和客户端架构的业务处理方法及业务处理系统
CN106156172A (zh) * 2015-04-16 2016-11-23 阿里巴巴集团控股有限公司 嵌入页面的会话过期处理方法和装置
EP3304865B1 (de) * 2015-05-26 2021-01-13 Idevices, LLC Systeme und verfahren für serverausfallsicherung und lastausgleich
US10218698B2 (en) * 2015-10-29 2019-02-26 Verizon Patent And Licensing Inc. Using a mobile device number (MDN) service in multifactor authentication
US10620996B2 (en) 2017-04-26 2020-04-14 Servicenow, Inc. Batching asynchronous web requests
CN109901049B (zh) * 2019-01-29 2021-05-04 厦门码灵半导体技术有限公司 检测集成电路用时序路径中异步路径的方法、装置
GB2582736B (en) * 2019-02-01 2022-02-16 Arm Ip Ltd Template-based registration
CN110673168B (zh) * 2019-09-05 2021-09-03 清华大学 异步多用户联合欺骗信号检测方法及装置
CN111818025B (zh) * 2020-06-23 2022-10-14 五八有限公司 一种用户终端的检测方法和装置
EP4173227A4 (de) * 2020-06-29 2024-02-28 Microsoft Technology Licensing, LLC Selektive sicherheitserhöhung in quellensteuerungsumgebungen

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05314032A (ja) * 1992-05-08 1993-11-26 Matsushita Electric Ind Co Ltd 電子掲示板装置
US6101528A (en) * 1996-03-27 2000-08-08 Intel Corporation Method and apparatus for discovering server applications by a client application in a network of computer systems
US5918228A (en) * 1997-01-28 1999-06-29 International Business Machines Corporation Method and apparatus for enabling a web server to impersonate a user of a distributed file system to obtain secure access to supported web documents
JP3088683B2 (ja) * 1997-05-29 2000-09-18 三菱電機株式会社 データ通信システム
EP2224673B1 (de) * 1997-07-30 2012-06-20 Visto Corporation System und Verfahren für den globalen und sicheren Zugriff auf vereinheitlichte Information in einem Computernetzwerk
US6609198B1 (en) * 1999-08-05 2003-08-19 Sun Microsystems, Inc. Log-on service providing credential level change without loss of session continuity
EP1168752A1 (de) * 2000-06-23 2002-01-02 Matra Nortel Communications Zugriffsteuerung in Client-Server-Systemen
US7350229B1 (en) * 2001-03-07 2008-03-25 Netegrity, Inc. Authentication and authorization mapping for a computer network
US20050198379A1 (en) * 2001-06-13 2005-09-08 Citrix Systems, Inc. Automatically reconnecting a client across reliable and persistent communication sessions
US7979914B2 (en) * 2001-06-25 2011-07-12 Audible, Inc. Time-based digital content authorization
US7380271B2 (en) * 2001-07-12 2008-05-27 International Business Machines Corporation Grouped access control list actions
US9015297B2 (en) * 2002-01-15 2015-04-21 Avaya Inc. Communication application server for converged communication services
US20040030887A1 (en) * 2002-08-07 2004-02-12 Harrisville-Wolff Carol L. System and method for providing secure communications between clients and service providers
US7363487B2 (en) * 2003-07-01 2008-04-22 International Business Machines Corporation Method and system for dynamic client authentication in support of JAAS programming model
US7562382B2 (en) * 2004-12-16 2009-07-14 International Business Machines Corporation Specializing support for a federation relationship
JP4692922B2 (ja) * 2005-03-16 2011-06-01 日本電気株式会社 ローカル端末、リモート端末、アプリケーションアクセス制御システム、その動作方法及び動作プログラム
US20070240230A1 (en) * 2006-04-10 2007-10-11 O'connell Brian M User-browser interaction analysis authentication system
GB0610113D0 (en) * 2006-05-20 2006-06-28 Ibm Method and system for the storage of authentication credentials
JP4989935B2 (ja) * 2006-07-21 2012-08-01 株式会社 日立東日本ソリューションズ セッション管理方法、それに用いられるサーバ、セッション管理プログラム、プログラムを記録した記録媒体
JP4267011B2 (ja) * 2006-08-24 2009-05-27 キヤノン株式会社 画像形成装置及び権限制御サーバ及び画像形成システム
CN101072234A (zh) * 2007-06-06 2007-11-14 杭州华三通信技术有限公司 点到点异步协商方法及装置
US20090164340A1 (en) * 2007-12-21 2009-06-25 Alex A. Lluch System and method for populating a gift registry using uploaded product information
US8347405B2 (en) * 2007-12-27 2013-01-01 International Business Machines Corporation Asynchronous java script and XML (AJAX) form-based authentication using java 2 platform enterprise edition (J2EE)
US8479268B2 (en) * 2009-12-15 2013-07-02 International Business Machines Corporation Securing asynchronous client server transactions

Also Published As

Publication number Publication date
GB201212055D0 (en) 2012-08-22
US8479268B2 (en) 2013-07-02
JP2013513880A (ja) 2013-04-22
TW201141159A (en) 2011-11-16
WO2011073125A1 (en) 2011-06-23
US20120233664A1 (en) 2012-09-13
US20130246515A1 (en) 2013-09-19
CN102771101B (zh) 2015-09-02
US20130297681A1 (en) 2013-11-07
US20110145891A1 (en) 2011-06-16
JP5613259B2 (ja) 2014-10-22
TWI505681B (zh) 2015-10-21
GB2489164A (en) 2012-09-19
US8984593B2 (en) 2015-03-17
US8819787B2 (en) 2014-08-26
US8474019B2 (en) 2013-06-25
CN102771101A (zh) 2012-11-07
DE112010004135B4 (de) 2019-07-11

Similar Documents

Publication Publication Date Title
DE112010004135B4 (de) Sicherung Asynchroner Client-Server-Transaktionen
DE102016123651B4 (de) Authentisierungskooperationssystem
DE102007033615B4 (de) Verfahren und Vorrichtung zum Umwandeln von Authentisierungs-Token zur Ermöglichung von Interaktionen zwischen Anwendungen
EP3125492B1 (de) Verfahren und system zum erzeugen eines sicheren kommunikationskanals für endgeräte
DE602004012870T2 (de) Verfahren und system zur benutzerauthentifizierung in einer benutzer-anbieterumgebung
DE112018005203T5 (de) Authentifizierung unter Verwendung von delegierten Identitäten
DE102011089580B3 (de) Verfahren zum Lesen von Attributen aus einem ID-Token
EP2769330B1 (de) Verfahren zum aufruf eines client-programms
DE112012003731T5 (de) Verfahren und Vorrichtung zum Schlüssel-Sharing in Verbindung mit dem Remote Desktop Protocol
DE112013004315T5 (de) Überprüfen der geographischen Adresse einer Arbeitslast in einer Cloud-Computing-Umgebung
DE112018004753T5 (de) Automatisches aufrüsten von einstufiger berechtigungsprüfung auf zweistufige berechtigungsprüfung über eine anwendungsprogrammierschnittstelle
EP2338255A2 (de) Verfahren, computerprogrammprodukt und system zur authentifizierung eines benutzers eines telekommunikationsnetzwerkes
DE112020000538T5 (de) Feinkörnige zugriffskontrolle auf token-grundlage
DE102006012646A1 (de) Systeme und Verfahren für adaptive Authentifizierung
DE112011102224B4 (de) Identitätsvermittlung zwischen Client- und Server-Anwendungen
DE112013002539B4 (de) Validierung mobiler Einheiten
DE112012002780T5 (de) Verfahren und Vorrichtung zur Berücksichtigung des Aufwands von Anwendungen basierend auf Kundenhardware
DE102011077218A1 (de) Zugriff auf in einer Cloud gespeicherte Daten
DE112017002794T5 (de) Verfahren und vorrichtung zum ausstellen eines berechtigungsnachweises für ein incident area network
DE112016002392T5 (de) Autorisierung in einem verteilten System unter Verwendung von Zugriffssteuerungslisten und Gruppen
DE112012001441B4 (de) Umsetzen von HTTP-Anforderungen in Vertrauenswürdigkeitsnachrichten zur Sicherheitsverarbeitung
WO2020143877A1 (de) Verfahren zum sicheren bereitstellen einer personalisierten elektronischen identität auf einem endgerät
DE102017107147A1 (de) Betrugssichere Autorisierung und Authentifizierung für sichere Interaktionen mit Smartphones
DE202020005753U1 (de) Verwalten von Benutzeridentitäten in einem verwalteten Multi-Tenant-Dienst
DE112012000780T5 (de) Verarbeiten von Berechtigungsprüfungsdaten

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R082 Change of representative

Representative=s name: RICHARDT PATENTANWAELTE PART GMBB, DE

Representative=s name: RICHARDT PATENTANWAELTE PARTG MBB, DE

R016 Response to examination communication
R016 Response to examination communication
R016 Response to examination communication
R016 Response to examination communication
R016 Response to examination communication
R018 Grant decision by examination section/examining division
R084 Declaration of willingness to licence
R020 Patent grant now final
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0029060000

Ipc: H04L0065000000