DE60218042T2 - Verfahren und system für einen dienstleistungsprozess zur bereitstellung eines dienstes zu einem kunden - Google Patents

Verfahren und system für einen dienstleistungsprozess zur bereitstellung eines dienstes zu einem kunden Download PDF

Info

Publication number
DE60218042T2
DE60218042T2 DE60218042T DE60218042T DE60218042T2 DE 60218042 T2 DE60218042 T2 DE 60218042T2 DE 60218042 T DE60218042 T DE 60218042T DE 60218042 T DE60218042 T DE 60218042T DE 60218042 T2 DE60218042 T2 DE 60218042T2
Authority
DE
Germany
Prior art keywords
service
client
cap
server
token
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.)
Expired - Lifetime
Application number
DE60218042T
Other languages
English (en)
Other versions
DE60218042D1 (de
Inventor
Johannes Hendrikus JOOSTEN
Hiddo Derk HUT
Geert Kleinhuis
Rene Van Buuren
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.)
Nederlandse Organisatie voor Toegepast Natuurwetenschappelijk Onderzoek TNO
Original Assignee
Nederlandse Organisatie voor Toegepast Natuurwetenschappelijk Onderzoek TNO
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 Nederlandse Organisatie voor Toegepast Natuurwetenschappelijk Onderzoek TNO filed Critical Nederlandse Organisatie voor Toegepast Natuurwetenschappelijk Onderzoek TNO
Application granted granted Critical
Publication of DE60218042D1 publication Critical patent/DE60218042D1/de
Publication of DE60218042T2 publication Critical patent/DE60218042T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • 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
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • 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/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • 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/16—Implementing security features at a particular protocol layer
    • H04L63/164—Implementing security features at a particular protocol layer at the network layer
    • 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/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • General Factory Administration (AREA)
  • Electrical Discharge Machining, Electrochemical Machining, And Combined Machining (AREA)

Description

  • HINTERGRUND DER ERFINDUNG
  • Die Erfindung betrifft ein Verfahren oder System für einen Dienstprozess zur Bereitstellung eines Dienstes für einen Client. Das Gebiet der Erfindung ist die Bereitstellung von Diensten über Computernetzwerke. Authentifizierung und Authorisierung von Clients durch Server stellen ein Problem dar, das in der Theorie "gelöst" worden ist, aber in der Praxis ist es ein anhaltendes Problem voller Fallen. Das praktische Ergebnis besteht darin, dass die sichere (d.h. authentifizierte und authorisierte) Bereitstellung von Diensten im Internet kaum jemals stattfindet und dass Nutzer wenig Vertrauen in existierende Dienste haben.
  • Für diese Situation lassen sich zahlreiche Gründe identifizieren, die umfassen:
    • – Wenn ein Dienst das SSL-Protokoll verwendet, um den Kunden zu authentifizieren und um die Dienstbereitstellung sicher zu machen, muss SSL dazu in der Lage sein, das dienstbereitstellende Protokoll zu transportieren ("tunneln"). Dies ist bei Protokollen nicht möglich, die auf UDP basieren. Einfacher UDP-basierte Protokolle sind DNS (Domain Name Service), TFTP (Trivial File Transfer Protocol), SNMP (Simple Network Management Protocol), das Syslog-Protokoll, usw. Komplexere Beispiele umfassen Video- und Audio-Streaming (wie etwa RealAudio und RealVideo), Mehrbenutzer-Spielprotokolle und Ähnliches.
    • – Wenn ein Dienst IPSEC verwendet, tritt das folgende Problem auf. IPSEC baut eine sichere Verbindung ("Transportrohr" bzw. "Transportpipe") zwischen zwei Maschinen (Computern, Routern oder Kombinationen von diesen) auf, eine, die von den Diensten (Client/Servern) getrennt ist, die sie verwenden. Mehrere Dienste können dieselbe IPSEC-Pipe verwenden. Die Verwendung der IPSEC-Authentifizierung als eine Authentifizierung für den Dienst ist ähnlich dazu, dass eine Person die Authentizität des Senders einer Postkarte akzeptiert, weil der Postbote dazu in der Lage ist, sich selbst mit Hilfe einer Identifikation zu identifizieren. Abgesehen davon ist IPSEC im Hinblick auf den Betrieb sowohl technisch als auch von dem Standpunkt der Sicherheit ein weitaus schwierigeres Protokoll als SSL.
    • – Wenn für die oben erwähnten Zwecke von einer Kombination von IPSEC und SSL Gebrauch gemacht wird, werden die übertragenen Daten zweimal verschlüsselt (einmal durch IPSEC, einmal durch SSL), was die Geschwindigkeit der Übertragung drastisch verringert und es schwieriger macht, die Verbindung in Betrieb zu setzen. Dies wird schnell inakzeptabel, insbesondere für Echtzeit-Datenübertragung (Multimediadienste).
    • – In dem Ausmaß, in dem Authentifizierung und Authorisierung stattfinden, sind sie gewöhnlich mit einem existierenden Dienst verwoben, was größere Probleme verursacht, da der Dienst selbst größer und komplexer wird.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Die Erfindung zielt darauf ab, es möglich zu machen:
    • 1) in einer einfachen Weise existierende Dienste, die wenig oder keine Authentifizierung/Authorisierung durchführen, in einer solchen Weise zu modifizieren, dass sie dann eine robuste Authentifizierung/Authorisierung besitzen,
    • 2) neue Dienste zu entwickeln, wobei der Authentifizierungs-/Authorisierungs-Teil von dem eigentlich dienstbereitstellenden Teil getrennt ist.
  • Die Erfindung weist wiederverwendbare Komponenten zur Implementierung von Authentifizierung und Authorisierung auf. Die Erfindung löst die zuvor erwähnten Probleme durch Trennen der Zuständigkeiten von Prozessen. Es wird ein Protokoll definiert, das angibt, wie diese Teile miteinander in einer solchen Weise kommunizieren, dass ein Dienstanbieter seinen Dienst für einen authentifizierten und authorisierten Kunden bereitstellen kann.
  • In einer bevorzugten Ausführungsform der Erfindung können vier Prozesse unterschieden werden, d.h.:
    • – Ein Clientprozess, zum Beispiel ein Standard-Browser, wie etwa Microsoft Internet Explorer, der im Folgenden auch als "Client" bezeichnet wird. Dieser Prozess befindet sich in der Sicherheitsdomäne des Dienstbenutzers.
    • – Ein Authentifizierungsprozess, der sich in der Sicherheitsdomäne von entweder dem Dienstanbieter oder einem vertrauenswürdigen Dritten befindet.
    • – Ein Dienstauthorisierungsprozess (DAP). Dieser Prozess – der eigentliche Authorisierungsprozess, in dem bestimmt wird, ob ein bestimmter Dienst für einen bestimmten Client bereitgestellt werden kann oder nicht bereitgestellt werden kann – befindet sich in der Sicherheitsdomäne des Dienstanbieters.
    • – Ein Dienstprozess (DP), der sich in der Sicherheitsdomäne des Dienstanbieters befindet. Gemäß der Erfindung kann auch eine Untermenge der Prozesse (mindestens einer) verwendet werden. Das Verfahren nach Anspruch 1 besteht aus den folgenden Schritten: a. der Client baut eine sichere Sitzung – zum Beispiel eine SSL-Sitzung – zu einem Authentifizierungsprozess auf und sendet eine Client-Kennung – zum Beispiel ein X.509-Zertifikat mit öffentlichem Schlüssel (X.509 Public Key Certificate) – und eine Dienstanforderung, die angibt, welcher Dienst benötigt wird, b. der Authentifizierungsprozess verifiziert die Client-Kennung und sendet die verifizierte Client-Kennung, bevorzugt mit einer Angabe über den. "Grad an Sicherheit" bezüglich der Authentizität der Client-Kennung, und die Dienstanforderung an einen Authorisierungsprozess; dies erlaubt es dem Authorisierungsprozess, zu wissen, (1) welcher Dienst (2) von wem benötigt wird, und (3) dass er (bevorzugt) einen bestimmten Grad an Sicherheit (der zum Beispiel durch Zertifikate der Klasse I, II oder III angegeben wird) bezüglich der Identität des Client hat, c. der Authorisierungsprozess prüft, ob der in der Dienstanforderung angegebene Dienst dem Client zur Verfügung gestellt werden kann und darf, und sendet das Ergebnis der Prüfung in der Form einer authorisierten Dienstanforderung zusammen mit einer bestimmten Gültigkeitsdauer zurück an den Authentifizierungsprozess; die authorisierte Dienstanforderung stellt eine Authorisierung dar, innerhalb der Gültigkeitsdauer damit zu beginnen, dem Client den Dienst zur Verfügung zu stellen, d. der Authentifizierungsprozess erzeugt einen Token und verbindet ihn mit der in dem vorhergehenden Schritt ausgegebenen Authorisierung (die authorisierte Dienstanforderung), e. der Authentifizierungsprozess sendet dann die Adresse des betreffenden Dienstprozesses und den Token, zum Beispiel mittels einer HTML-Seite, die diese Adresse und diesen Token als einen Hypertext-Zink enthält, wodurch der Browser des Client zu der (Hypertext-Link-)Adresse des Dienstprozesses umgeleitet wird, an den Client, f. der Client nimmt (mittels des Hypertext-Links) mit dem Dienstprozess Verbindung auf und sendet den vom Authentifizierungsprozess erhaltenen Token (die Sitzung zwischen dem Client und dem Verifizierungsprozess kann beendet werden), g. der Dienstprozess sendet dem Authentifizierungsprozess den vom Client erhaltenen Token, h. der Authentifizierungsprozess holt die mit dem Token verbundene, authorisierte Dienstanforderung ("Authorisierung"), prüft, ob die Gültigkeitsdauer in Ordnung ist, und sendet dann die authorisierte Dienstanforderung an den Dienstprozess. Es ist darauf hinzuweisen, dass diese Situation genau dieselbe ist, als wenn keine Authentifizierung und Authorisierung stattgefunden hätte und der Clientprozess die Dienstanforderung unmittelbar an den Dienstprozess gesendet hätte. Dies ist deshalb der Fall, weil der Clientprozess die Sitzung zwischen dem Client und dem Dienstprozess gestartet hat und das verwendete Protokoll dasselbe Protokoll ist, das der Dienstprozess in anderen Fällen für diesen Zweck verwendet haben würde, i. dann stellt der Dienstprozess den vom Client benötigten Dienst bereit.
  • Das System gemäß Anspruch 3 weist die Mittel zum Ausführen der oben erwähnten Schritte in dem Verfahren auf. Die beschriebene Erfindung hat die folgenden Vorteile:
    • 1) Die Erfindung verwendet Standardprotokolle.
    • 2) Die Erfindung muss nur auf der Serverseite implementiert werden (d.h., wo der Authentifizierungsprozess, der Authorisierungsprozess und der Dienstprozess aktiviert worden sind). Weit verbreitete Browser (wie etwa Microsoft Internet Explorer, Netscape Navigator und Ähnliche) sind ohne jegliche Modifikationen auf der Clientseite verwendbar.
    • 3) Es ist keine Extraunterstützung (wie etwa eine Beratungsstelle) für Endbenutzer erforderlich.
    • 4) Mit minimalen Modifikationen kann jeder elektronische Dienst, der (noch) nicht eine Authentifizierung/Authorisierung ausführt, die Erfindung ohne Rücksicht auf das Protokoll verwenden, das der Dienst verwendet.
    • 5) Die Erfindung verwendet keine durch einen Server aufgebaute Sitzungen und (a) erfordert infolgedessen keine speziellen Modifikationen an Firewalls und (b) kann auch verwendet werden, wenn sich der Client in einem Netzwerk befindet, das mit dem Internet über Netzwerkadressumsetzung (Network Address Translation, NAT) verbunden ist.
    • 6) Die Erfindung erlaubt eine einfache Trennung von Geschäftsprozessen und Betriebsprozessen, während die Schnittstellen zwischen den verschiedenen Prozessen auch sehr einfach sind. Das macht es leicht, eine Situation zu vermeiden, in der ein Dienst als eine unflexible, monolithische Einheit erzeugt wird.
  • REFERENZEN
    • – SSL (ftp://ds.internic.net/internet-drafts/draft-freier-ssl-version3-02.txt). Dies ist ein Internetentwurf mit dem Datum 18. November 1996. Das SSLv3-Protokoll ist nicht formal standardisiert worden, aber ist der de facto Standard. Das Protokoll bietet Datenschutz und Zuverlässigkeit zwischen zwei kommunizierenden Anwendungen (Prozessen). Es erlaubt, dass Client/Server-Anwendungen in einer Weise kommunizieren, die ausgestaltet ist, um zu verhindern, dass Dritte dazu in der Lage sind, die Kommunikation abzuhören, Nachrichten zu ändern oder Nachrichten hinzuzufügen. In dem Protokollstapel erwartet SSL ein zuverlässiges Transportprotokoll (zum Beispiel wie TCP, aber nicht UDP) unter sich.
    • – IPSEC (http://www.ietf.org/rfc/rfc2401.txt). Der Zweck von IPSEC besteht darin, sowohl in IPv4- als auch in IPv6-Umgebungen verschiedene Sicherheitsdienste für einen Verkehr auf der IP-Schicht anzubieten. Auch wenn IPSEC einen Teil der Dienstsicherheit bilden kann, ist es nicht dazu in der Lage, einen gesamten Dienst sicher zu machen, weil IPSEC auf der IP-Ebene arbeitet, und es muss möglich sein, die Sicherheit von Diensten auch auf höheren Ebenen zu gewährleisten.
    • – Es existieren auch geschlossene Systeme zur Authentifizierung/Authorisierung. Siehe zum Beispiel RABO Bank für elektronischen Geldverkehr, das EasyPay-System von Shell, Digitale Briefmarken (Digital Postal Stamps) von PTT Post und Ähnliches. Systeme dieser Art haben den Nachteil, dass der Kunde zusätzliche Hardware benötigt, bevor er die Dienste verwenden kann.
  • Die Patentanmeldung WO/0069110 zeigt ein Verfahren, bei dem der Authentifizierungsprozess bezüglich der Dienstbereitstellung extern angeordnet ist.
  • IMPLEMENTIERUNG
  • 1 zeigt eine Implementierung der Erfindung und stellt ein System mit vier Prozessen dar, d.h. vier Hardware/Software-Modulen (Computern, Servern, Terminals, usw.), auf denen diese Prozesse laufen und über ein Netzwerk (wie etwa das Internet) miteinander in Kontakt treten können.
  • 1 zeigt einen Clientprozess (C), der mit Hilfe eines Web-Browsers wie Microsoft Internet Explorer auf einem PC eines Benutzers implementiert ist, einen Client-Authentifizierungsprozess (CAP), der mit Hilfe von Prozeduren aus Standardbibliotheken implementiert ist, einen Dienstauthorisierungsprozess (DAP) und einen Dienstprozess (DP), der einen von dem Benutzer mit Hilfe seines/ihres Client (C) angeforderten Dienst bereitstellen kann. Jeder Prozess fällt in eine Sicherheitsdomäne, d.h. eine Person oder Authorität verwaltet den Prozess und trägt die Konsequenzen dessen, was der Prozess tut oder nicht tut. Zum Beispiel fällt der Prozess C unter die Sicherheitsdomäne des Benutzers, während CAP unter die Sicherheitsdomäne des betreffenden Dienstanbieters (SP) oder eines vertrauenswürdigen Dritten fällt, während die DAP und DP unter die Sicherheitsdomäne des Dienstanbieters fallen.
  • In diesem Zusammenhang wird ein "Protokoll" als ein Verfahren verstanden, mit dem zwei (Computer-)Prozesse miteinander kommunizieren können. Diese können zum Beispiel Internetprotokolle, aber auch Prozeduraufrufe (wenn die Prozesse auf derselben Maschine laufen) oder andere Protokolle sein.
  • Die gezeigte Implementierung der Erfindung verwendet die folgenden Kommunikationsprotokolle:
    • – SSL (Secure Sockets Layer Protocol) oder TLS (Transport Layer Security Protocol). Diese sind wohl bekannte und gut dokumentierte Protokolle (siehe Referenzen).
    • – DSP (Domain Secure Protocol). Dies ist nicht ein existierendes Protokoll, sondern ein "Platzhalter"-Name für irgendein Protokoll, das entweder (1) eine Kommunikation zwischen zwei Prozessen innerhalb von ein und derselben Sicherheitsdomäne bereitstellt und (2) durch den Administrator dieser Sicherheitsdomäne als "sicher" zur Verwendung innerhalb dieser Sicherheitsdomäne bezeichnet worden ist oder (1) eine Kommunikation zwischen einem Prozess in der Sicherheitsdomäne eines TTP und einem Prozess in der Sicherheitsdomäne des betreffenden Dienstanbieters bereitstellt und (2) durch die Administratoren dieser Sicherheitsdomänen als "sicher" zur Verwendung innerhalb dieser Sicherheitsdomänen bezeichnet worden ist.
    • – DSP1, ein DSP-Protokoll, das zwischen den CAP- und DAP-Prozessen verwendet wird.
    • – DSP2, ein DSP-Protokoll, das zwischen den CAP- und DP-Prozessen verwendet wird.
    • – AP (Application Protocol). Dies ist nicht ein existierendes Protokoll, sondern ein "Platzhalter"-Name für das Protokoll zwischen dem Clientprozess (C) und dem Dienstprozess (DP). Dieses Protokoll muss die Sicherheitsanforderungen (und andere Anforderungen) erfüllen, die durch den Dienstanbieter für das Protokoll festgeschrieben sind.
  • Die Prozedur ist wie folgt:
    • – Eine Verbindung wird zwischen Prozess C und CAP aufgebaut. Diese Verbindung verwendet das SSL- oder TLS-Protokoll. Das Protokoll ist in einer solchen Weise eingestellt, dass während des Aufbaus dieser Verbindung: (a) C den CAP auf Basis eines durch den CAP zu sendenden Server-Zertifikats authentifiziert, das durch einen C bekannten Teilnehmer herausgegeben worden ist ("vertrauenswürdiger Dritter"), (b) CAP eine Liste von Client-Zertifikat-Herausgebern, die von CAP akzeptiert werden, an C sendet. Für jeden Zertifikattyp und -herausgeber hat CAP ferner den Grad an Sicherheit, der von dem Dienstanbieter zur Authentifizierung von Zertifikaten dieses Typs und Herausgebers angewendet wird.
    • – CAP initiiert unter Verwendung des DSP1-Protokolls (siehe oben) eine Verbindung zwischen CAP und DAP.
    • – C initiiert unter Verwendung des AP-Protokolls (siehe oben) eine Verbindung zwischen C und DP.
    • – Eine Verbindung wird zwischen Dienstprozess DP und dem CAP aufgebaut. Dieser Prozess verwendet das DSP2-Protokoll (siehe oben). DP oder CAP kann diese Verbindung aufbauen. Die Erfindung setzt die Existenz eines (elektronischen) "Vertrags" zwischen Nutzern und Dienstanbietern voraus, der spezifiziert, welche Dienste der DP dem Nutzer zu welchen Bedingungen bereitstellen darf. Diese Bedingungen können möglicherweise Anforderungen in Bezug auf die Art von Zertifikat, das ein Client zur Authentifizierung senden darf, Parameter, die den Dienst beein flussen können, die Gebühr, die der Dienstanbieter von C zur Bereitstellung des angeforderten Dienstes fordert, usw. auferlegen. Die zuvor erwähnten Dienstanforderungen bestehen aus einem Satz von Dienstparametern und nehmen die Form einer Parameterliste an, die zu einer URL hinzugefügt werden kann. Wo auf "Authorisierung" Bezug genommen wird, umfasst dieser Begriff (1) die Identität des Benutzers (über den Client C), für den die Authorisierung beabsichtigt ist, (2) eine Dienstanforderung, für die die Authorisierung herausgegeben wurde, (3) ein Gültigkeitsintervall (d.h. ein Zeitintervall, innerhalb dessen die Authorisierung gültig ist) und (4) eine IP-Adresse, von der die Authorisierung angefordert wurde. Die Dienstanforderung nimmt die Form einer Parameterliste an, die einer URL hinzugefügt wurde. Die Authorisierung besitzt ferner die Eigenschaft, dass der Dienstanbieter (SP) einen ausreichenden Grad an Sicherheit hat, dass ein Client, für den die Authorisierung erzeugt wurde, dazu in der Lage ist, innerhalb des Gültigkeitsintervalls Zugriff auf den Dienst zu erhalten.
  • Der "Token", auf den oben Bezug genommen wurde, besteht aus einer Reihe von Bits, die der CAP auf Basis einer Authorisierung in einer solchen Weise erzeugt, dass der Token die folgenden Eigenschaften besitzt:
    • (a) CRP kann die Authorisierung (die die Erzeugung des Tokens zur Folge hatte) auf der Basis des Tokens zumindest während des Zeitintervalls reproduzieren, innerhalb dessen die Authorisierung gültig ist.
    • (b) Der Token ist für eine solche Zeit gültig, wie die Authorisierung gültig ist.
    • (c) Das Risiko, dass ein Dritter dazu in der Lage ist, einen gültigen Token zu raten, ist so klein, dass es vernachlässigbar ist (zum Beispiel geringer als 2–50).
    • (d) Zwei oder mehr unterschiedliche (gültige) Authorisierungen sind nicht gleichzeitig mit ein und demselben Token verbunden. Wenn CAP den Token erzeugt und auch interpretiert, ist CAP dazu in der Lage, die in dem Token enthaltenen Daten zu bestimmen. Die Tokengröße ist (nicht in der Theorie, aber wahrscheinlich in der Praxis) beschränkt durch: – die Größe der URL des DP, – den Zeichensatz (ASCII), der für den Token zulässig ist, und – die durch den Client-Browser zugelassene maximale Länge der URL.
  • Ein in ASCII umgesetzter sicherer Hash (oder ein Teil davon) einer Authorisierung könnte ein guter Token sein. Das Diagramm in 2 zeigt, wie das vorgestellte System arbeitet:
    • [1] Der Nutzer surft zu dem benötigten Dienst, indem er die Adresse (URL) (zum Beispiel www.service.com) in den Browser (Client) eingibt, was bewirkt, dass der Browser C eine SSL-Verbindung zu dem betreffenden CAP-Server aufbaut, wodurch der Client C und der CAP-Server einander authentifizieren (siehe oben unter "Aufbau einer SSL/TLS-Verbindung"). Als eine Folge dieser Aktion hat CAP die Identität des Nutzers C (ID), das Zertifikat mit öffentlichem Schlüssel von C, gegenüber dem die ID geprüft wurde, Alvl (was ein Parameter ist, der angibt, in welchem Ausmaß der Dienstanbieter dieser Prüfung vertraut) und die IP-Adresse (IP) zu seiner Verfügung, von der C die Verbindung aufgebaut hat.
    • [2] C sendet eine Dienstanforderung sreq an CAP (über die gerade aufgebaute SSL-Verbindung).
    • [3] CAP sendet die sreq, ID, Alvl und IP an den DAP-Prozess (unter Verwendung des DSP1-Protokolls).
    • [4] Wenn DAP feststellt, dass der Nutzer C keine Berechtigung für den durch C angeforderten Dienst hat (zum Beispiel weil die benötigte Dienstbereitstellung nicht durch einen Vertrag definiert ist), endet das Protokoll. Wenn DAP feststellt, dass eine Berechtigung für den Dienst vorliegt, bestimmt DAP eine alternative Dienstanforderung, die (a) durch einen Vertrag abgedeckt ist und (b) sreq so weit wie möglich gleicht. DAP bestimmt ferner ein Zeitintervall TI (Gültigkeitsintervall), innerhalb dessen die Dienstbereitstellung beginnen muss.
    • [5] DAP sendet eine Authorisierung (die sreq', TI, ID und IP umfasst) an CAP (unter Verwendung des DSP1-Protokolls).
    • [5] DAP sendet eine Authorisierung A (die aus sreq', TI, ID und IP besteht) an CAP (unter Verwendung des DSP1-Protokolls).
    • [6] CAP erzeugt auf Basis der durch DAP bereitgestellten Authorisierung (A) einen Token mit all den Eigenschaften eines Tokens (siehe oben).
    • [7] CAP sendet (in der bereits aufgebauten SSL-Sitzung) eine HTML-Seite an den Client, die einen Hypertext-Link zu dem Server DP enthält, wobei ein solcher Hypertext-Zink den Token als einen Parameter enthält, wobei alles in einer solchen Weise geschieht, dass der Browser nach einer Wartezeit von Null Sekunden zu diesem Hypertext-Zink wechselt. Diese Aktion beendet die SSL-Sitzung zwischen C und CAP (das erfundene Protokoll endet noch nicht).
    • [8] Durch Interpretieren dieser HTML-Seite baut der Client-Browser gemäß dem in dem Hyptertext-Zink spezifizierten CAP-Protokoll eine Sitzung zu dem Server DP auf. Außerdem wird der Token mittels dieses Protokolls zu DP gesendet.
    • [9] DP sendet den Token sowie die IP-Adresse (IP) des Client, der die Sitzung gestartet hat, zu CAP (unter Verwendung des DSP2-Protokolls).
    • [10] CAP prüft, ob den Token eine gültige Authorisierung begleitet. Wenn dies nicht der Fall ist, endet das Protokoll. Außerdem findet CAP heraus, ob: – IP dieselbe IP-Adresse (IP) ist, die in der Authorisierung angegeben ist, – die aktuelle Zeit in das Zeitintervall TI fällt, das in der Authorisierung angegeben ist. Wenn irgendeiner dieser Punkte inkorrekt ist, endet das Protokoll.
    • [11] CAP sendet die in der Authorisierung angegebene Dienstanforderung (sreq) an DP (unter Verwendung des DSP2-Protokolls).
    • [12] DP beginnt nun damit, C gemäß der Dienstanforderung unter Verwendung des AP-Protokolls einen Dienst bereitzustellen, und gleichzeitig endet das erfundene Protokoll.
  • Es müssen die folgenden Kommentare gemacht werden:
    • 1. Wenn sich ein Prozess in der Sicherheitsdomäne eines Rechtssubjekts befindet, bedeutet dies, dass das Rechtssubjekt für die Sicherheitsaspekte des Prozesses verantwortlich ist (d.h. es verwaltet die Sicherheit dieses Prozesses und trägt in Bezug auf die Sicherheit die Konsequenzen dessen, was der Prozess – unbeabsichtigt oder in anderer Weise – tut oder nicht tut.
    • 2. Der "Grad an Sicherheit" Alvl gibt an, wie viel Vertrauen das Geschäft in die Angabe hat, dass "der Kunde ID genannt wird". Schließlich kann dieses Vertrauen von dem Grad abhängen, zu dem der Zertifikatherausgeber die Identität geprüft hat, und dieser Umstand ist in dem Fall von zum Beispiel Zertifikaten der Klasse I, II und III unterschiedlich.
    • 3. Auch wenn sich der Standard auf Zertifikatherausgeber bezieht, ist die Situation in der Praxis so, dass ein Zertifikatherausgeber verschiedene Arten von Zertifikaten (zum Beispiel Zertifikate der Klasse I, II und III) herausgeben kann, wodurch die Bedingungen, zu denen ein Zertifikattyp herausgegeben wird, von denjenigen verschieden sind, die mit einem anderen Typ von Zertifikat verbunden sind. Dementsprechend kann sich das Vertrauen, das ein Dienstanbieter in unterschiedliche Zertifikattypen hat, unterscheiden, und jeder Zertifikattyp sollte einen "Grad an Sicherheit" Alvl haben. Jedoch wird auch der "angesehene Name" des Herausgebers, wie er in dem Zertifikat erscheint, verwendet, um diese Zertifikattypen anzugeben. Daher ist es möglich, in diesem Fall das Senden einer Liste von Zertifikatherausgebern ausreichen zu lassen.

Claims (4)

  1. Verfahren für einen Dienstprozess zur Bereitstellung eines Dienstes für einen Client mit den folgenden Schritten: a. der Client (C) baut eine sichere Sitzung zu einem Authentifizierungsprozess (CAP) auf und sendet eine Client-Kennung und eine Dienstanforderung, die angibt, welcher Dienst benötigt wird, b. der Authentifizierungsprozess (CAP) verifiziert die Client-Kennung und sendet die verifizierte Client-Kennung und die Dienstanforderung an einen Authorisierungsprozess (DAP), c. der Authorisierungsprozess (DAP) prüft, ob der in der Dienstanforderung angegebene Dienst dem Client (C) zur Verfügung gestellt werden kann und darf, und sendet das Ergebnis der Prüfung in Form einer authorisierten Dienstanforderung, die eine Gültigkeitsdauer enthält, zum Authentifizierungsprozess (CAP), d. der Authentifizierungsprozess (CAP) erzeugt einen Token, der mit der authorisierten Dienstanforderung verbunden ist, e. über die sichere Sitzung sendet der Authentifizierungsprozess die Adresse des betreffenden Dienstprozesses und den Token an den Client (C), f. der Client (C) nimmt mit dem Dienstprozess (DP) Verbindung auf und sendet dem Dienstprozess (DP) den vom Authentifizierungsprozess (CAP) erhaltenen Token, g. der Dienstprozess sendet dem Authentifizierungsprozess (CAP) den vom Client (C) erhaltenen Token, h. der Authentifizierungsprozess (CAP) holt die mit dem Token verbundene, authorisierte Dienstanforderung, prüft, ob die Gültigkeitsdauer in Ordnung ist, und sendet dann die authorisierte Dienstanforderung an den Dienstprozess (DP), i. dann stellt der Dienstprozess (DP) den vom Client (C) benötigten Dienst bereit.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Authentifizierungsprozess (CAP) in dem oben unter b. beschriebenen Schritt zusätzlich zur verifizierten Client-Kennung eine Angabe über den "Grad an Sicherheit" bezüglich der Authentizität der Client-Kennung an den Authorisierungsprozess (DAP) sendet.
  3. System für einen Dienstserver zur Bereitstellung eines Dienstes für einen Client, wobei das System einen Client (C), einen Authentifizierungsserver (CAP), einen Authorisierungsserver (DAP) und einen Dienstserver (DP) aufweist, wobei: a. der Client (C) ein Mittel zum Aufbauen einer sicheren Sitzung zu einem Authentifizierungsserver (CAP) und zum Senden einer Client-Kennung und einer Dienstanforderung, die angibt, welcher Dienst benötigt wird, an diesen Authentifizierungsserver (CAP) enthält, b. der Authentifizierungsserver (CAP) ein Mittel zum Verifizieren der vom Client (C) erhaltenen Client-Kennung und zum Senden der verifizierten Client- Kennung und der Dienstanforderung an einen Authorisierungsserver (DAP) enthält, c. der Authorisierungsserver (DAP) ein Mittel zum Prüfen, ob der in der Dienstanforderung angegebene Dienst dem Client (C) zur Verfügung gestellt werden kann und darf, und ein Mittel zum Zurücksenden des Ergebnisses der Prüfung in Form einer authorisierten Dienstanforderung, die mit einer vom Authorisierungsserver (DAP) bestimmten Gültigkeitsdauer versehen ist, an den Authentifizierungsserver (CAP) enthält, d. der Authentifizierungsserver (CAP) ein Mittel zum Erzeugen eines mit der authorisierten Dienstanforderung verbundenen Tokens enthält, e. der Authentifizierungsserver (CAP) ein Mittel zum Senden der Adresse des relevanten Dienstservers (DP) und des Tokens über die sichere Sitzung an den Client (C) enthält, f. der Client (C) ein Mittel zum Senden des empfangenen Tokens an den Dienstserver (DP) enthält, g. der Dienstserver (DP) ein Mittel zum Senden des vom Client empfangenen Tokens an den Authentifizierungsserver (CAP) enthält, h. der Authentifizierungsserver (CAP) Mittel zum Holen der authorisierten Dienstanforderung, die mit dem Token verbunden ist, zum Prüfen, ob die Gültigkeitsdauer in Ordnung ist, und dann zum Senden der authorisierten Dienstanforderung an den Dienstserver (DP) enthält, i. der Dienstserver (DP) ein Mittel zum anschließenden Bereitstellen des benötigten Dienstes für den Client (C) enthält.
  4. System nach Anspruch 3, dadurch gekennzeichnet, dass der Authentifizierungsserver (CAP) zusätzlich dazu, dass er das oben unter b. erwähnte Mittel zum Verifizieren der vom Client (C) erhaltenen Client-Kennung und zum Senden der verifizierten Client-Kennung und der Dienstanforderung an einen Authorisierungsserver (DAP) enthält, ferner ein Mittel zur Berechnung einer Angabe über den "Grad an Sicherheit" bezüglich der Authentizität der Client-Kennung und zum Senden dieser Angabe an den Authorisierungsserver (DAP) enthält.
DE60218042T 2001-07-09 2002-06-27 Verfahren und system für einen dienstleistungsprozess zur bereitstellung eines dienstes zu einem kunden Expired - Lifetime DE60218042T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
NL1018494A NL1018494C2 (nl) 2001-07-09 2001-07-09 Methode en systeem voor het door een dienstproces aan een client leveren van een dienst.
NL1018494 2001-07-09
PCT/EP2002/007261 WO2003007571A1 (en) 2001-07-09 2002-06-27 Method and system for a service process to provide a service to a client

Publications (2)

Publication Number Publication Date
DE60218042D1 DE60218042D1 (de) 2007-03-22
DE60218042T2 true DE60218042T2 (de) 2007-11-08

Family

ID=19773693

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60218042T Expired - Lifetime DE60218042T2 (de) 2001-07-09 2002-06-27 Verfahren und system für einen dienstleistungsprozess zur bereitstellung eines dienstes zu einem kunden

Country Status (7)

Country Link
US (1) US7565554B2 (de)
EP (1) EP1405490B1 (de)
AT (1) ATE353515T1 (de)
DE (1) DE60218042T2 (de)
ES (1) ES2280553T3 (de)
NL (1) NL1018494C2 (de)
WO (1) WO2003007571A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10511587B2 (en) 2015-06-11 2019-12-17 Siemens Aktiengesellschaft Authorization apparatus and method for an authorized issuing of an authentication token for a device

Families Citing this family (113)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2826811B1 (fr) * 2001-06-27 2003-11-07 France Telecom Procede d'authentification cryptographique
US7707066B2 (en) * 2002-05-15 2010-04-27 Navio Systems, Inc. Methods of facilitating merchant transactions using a computerized system including a set of titles
US7814025B2 (en) * 2002-05-15 2010-10-12 Navio Systems, Inc. Methods and apparatus for title protocol, authentication, and sharing
US7707121B1 (en) 2002-05-15 2010-04-27 Navio Systems, Inc. Methods and apparatus for title structure and management
CN1701561B (zh) * 2003-07-11 2010-05-05 日本电信电话株式会社 基于地址的验证系统及其装置和程序
WO2005015870A1 (en) * 2003-08-01 2005-02-17 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for routing a service request
CN100499536C (zh) * 2003-10-22 2009-06-10 华为技术有限公司 无线局域网中选定业务的解析接入处理方法
US7783891B2 (en) * 2004-02-25 2010-08-24 Microsoft Corporation System and method facilitating secure credential management
US7721340B2 (en) 2004-06-12 2010-05-18 Microsoft Corporation Registry protection
US7584509B2 (en) 2004-06-12 2009-09-01 Microsoft Corporation Inhibiting software tampering
KR101203245B1 (ko) 2004-06-12 2012-11-20 마이크로소프트 코포레이션 소프트웨어 보안
US8296562B2 (en) 2004-07-15 2012-10-23 Anakam, Inc. Out of band system and method for authentication
EP1766839B1 (de) 2004-07-15 2013-03-06 Anakam, Inc. System und verfahren zum blockieren eines unautorisierten netzwerk-log bei der verwendung eines gestohlenen passworts
US8533791B2 (en) 2004-07-15 2013-09-10 Anakam, Inc. System and method for second factor authentication services
US7676834B2 (en) 2004-07-15 2010-03-09 Anakam L.L.C. System and method for blocking unauthorized network log in using stolen password
US8528078B2 (en) 2004-07-15 2013-09-03 Anakam, Inc. System and method for blocking unauthorized network log in using stolen password
JP2006054656A (ja) * 2004-08-11 2006-02-23 Nec Corp Ｐｔｔ通信システム、ｐｔｔ通信方法、ｐｔｔ通信サーバ
JP2006086907A (ja) * 2004-09-17 2006-03-30 Fujitsu Ltd 設定情報配布装置、方法、プログラム、媒体、及び設定情報受信プログラム
US8213034B2 (en) 2004-10-08 2012-07-03 Sharp Laboratories Of America, Inc. Methods and systems for providing remote file structure access on an imaging device
US8001586B2 (en) 2004-10-08 2011-08-16 Sharp Laboratories Of America, Inc. Methods and systems for imaging device credential management and authentication
US8024792B2 (en) 2004-10-08 2011-09-20 Sharp Laboratories Of America, Inc. Methods and systems for imaging device credential submission
US8060930B2 (en) 2004-10-08 2011-11-15 Sharp Laboratories Of America, Inc. Methods and systems for imaging device credential receipt and authentication
US8006293B2 (en) * 2004-10-08 2011-08-23 Sharp Laboratories Of America, Inc. Methods and systems for imaging device credential acceptance
US8120799B2 (en) 2004-10-08 2012-02-21 Sharp Laboratories Of America, Inc. Methods and systems for accessing remote, descriptor-related data at an imaging device
US8032579B2 (en) 2004-10-08 2011-10-04 Sharp Laboratories Of America, Inc. Methods and systems for obtaining imaging device notification access control
US8018610B2 (en) 2004-10-08 2011-09-13 Sharp Laboratories Of America, Inc. Methods and systems for imaging device remote application interaction
US8060921B2 (en) * 2004-10-08 2011-11-15 Sharp Laboratories Of America, Inc. Methods and systems for imaging device credential authentication and communication
US8049677B2 (en) 2004-10-08 2011-11-01 Sharp Laboratories Of America, Inc. Methods and systems for imaging device display element localization
US7920101B2 (en) 2004-10-08 2011-04-05 Sharp Laboratories Of America, Inc. Methods and systems for imaging device display standardization
US8384925B2 (en) 2004-10-08 2013-02-26 Sharp Laboratories Of America, Inc. Methods and systems for imaging device accounting data management
US7870185B2 (en) * 2004-10-08 2011-01-11 Sharp Laboratories Of America, Inc. Methods and systems for imaging device event notification administration
US8171404B2 (en) 2004-10-08 2012-05-01 Sharp Laboratories Of America, Inc. Methods and systems for disassembly and reassembly of examination documents
US8006292B2 (en) * 2004-10-08 2011-08-23 Sharp Laboratories Of America, Inc. Methods and systems for imaging device credential submission and consolidation
US8115946B2 (en) 2004-10-08 2012-02-14 Sharp Laboratories Of America, Inc. Methods and sytems for imaging device job definition
US8051125B2 (en) 2004-10-08 2011-11-01 Sharp Laboratories Of America, Inc. Methods and systems for obtaining imaging device event notification subscription
US8006176B2 (en) * 2004-10-08 2011-08-23 Sharp Laboratories Of America, Inc. Methods and systems for imaging-device-based form field management
US8115944B2 (en) 2004-10-08 2012-02-14 Sharp Laboratories Of America, Inc. Methods and systems for local configuration-based imaging device accounting
US7978618B2 (en) 2004-10-08 2011-07-12 Sharp Laboratories Of America, Inc. Methods and systems for user interface customization
US8065384B2 (en) 2004-10-08 2011-11-22 Sharp Laboratories Of America, Inc. Methods and systems for imaging device event notification subscription
US8125666B2 (en) 2004-10-08 2012-02-28 Sharp Laboratories Of America, Inc. Methods and systems for imaging device document management
US8115945B2 (en) 2004-10-08 2012-02-14 Sharp Laboratories Of America, Inc. Methods and systems for imaging device job configuration management
US8051140B2 (en) 2004-10-08 2011-11-01 Sharp Laboratories Of America, Inc. Methods and systems for imaging device control
US8001183B2 (en) 2004-10-08 2011-08-16 Sharp Laboratories Of America, Inc. Methods and systems for imaging device related event notification
US8156424B2 (en) 2004-10-08 2012-04-10 Sharp Laboratories Of America, Inc. Methods and systems for imaging device dynamic document creation and organization
US8120793B2 (en) * 2004-10-08 2012-02-21 Sharp Laboratories Of America, Inc. Methods and systems for displaying content on an imaging device
US7970813B2 (en) 2004-10-08 2011-06-28 Sharp Laboratories Of America, Inc. Methods and systems for imaging device event notification administration and subscription
US8115947B2 (en) 2004-10-08 2012-02-14 Sharp Laboratories Of America, Inc. Methods and systems for providing remote, descriptor-related data to an imaging device
US8230328B2 (en) 2004-10-08 2012-07-24 Sharp Laboratories Of America, Inc. Methods and systems for distributing localized display elements to an imaging device
US7934217B2 (en) 2004-10-08 2011-04-26 Sharp Laboratories Of America, Inc. Methods and systems for providing remote file structure access to an imaging device
US7873718B2 (en) 2004-10-08 2011-01-18 Sharp Laboratories Of America, Inc. Methods and systems for imaging device accounting server recovery
US8237946B2 (en) 2004-10-08 2012-08-07 Sharp Laboratories Of America, Inc. Methods and systems for imaging device accounting server redundancy
US8001587B2 (en) * 2004-10-08 2011-08-16 Sharp Laboratories Of America, Inc. Methods and systems for imaging device credential management
US8015234B2 (en) 2004-10-08 2011-09-06 Sharp Laboratories Of America, Inc. Methods and systems for administering imaging device notification access control
US8023130B2 (en) 2004-10-08 2011-09-20 Sharp Laboratories Of America, Inc. Methods and systems for imaging device accounting data maintenance
US8032608B2 (en) 2004-10-08 2011-10-04 Sharp Laboratories Of America, Inc. Methods and systems for imaging device notification access control
US8120797B2 (en) * 2004-10-08 2012-02-21 Sharp Laboratories Of America, Inc. Methods and systems for transmitting content to an imaging device
US8035831B2 (en) 2004-10-08 2011-10-11 Sharp Laboratories Of America, Inc. Methods and systems for imaging device remote form management
US7873553B2 (en) 2004-10-08 2011-01-18 Sharp Laboratories Of America, Inc. Methods and systems for authorizing imaging device concurrent account use
US7969596B2 (en) 2004-10-08 2011-06-28 Sharp Laboratories Of America, Inc. Methods and systems for imaging device document translation
US7624433B1 (en) * 2005-02-24 2009-11-24 Intuit Inc. Keyfob for use with multiple authentication entities
US8428484B2 (en) 2005-03-04 2013-04-23 Sharp Laboratories Of America, Inc. Methods and systems for peripheral accounting
CN100583761C (zh) * 2005-05-16 2010-01-20 联想(北京)有限公司 一种统一认证的实现方法
US8213412B2 (en) * 2005-09-29 2012-07-03 Comcast Cable Holdings, Llc System and method for providing multimedia services utilizing a local proxy
US7996682B2 (en) * 2005-10-17 2011-08-09 Microsoft Corporation Secure prompting
EP1788773A1 (de) * 2005-11-18 2007-05-23 Alcatel Lucent Verfahren und Vorrichtungen zur Anforderung eines Medienpostens und zur Voraberstellung eines Tokens
US8099508B2 (en) * 2005-12-16 2012-01-17 Comcast Cable Holdings, Llc Method of using tokens and policy descriptors for dynamic on demand session management
FR2895632A1 (fr) * 2005-12-22 2007-06-29 Gemplus Sa Controle d'acces a des services en mode multidiffusion dans un dispositif terminal
US9177338B2 (en) 2005-12-29 2015-11-03 Oncircle, Inc. Software, systems, and methods for processing digital bearer instruments
EP1977381A4 (de) 2005-12-29 2014-01-01 Oncircle Inc Software, systeme und verfahren zum verarbeiten von digitalen trägerinstrumenten
US20070250711A1 (en) * 2006-04-25 2007-10-25 Phonified Llc System and method for presenting and inputting information on a mobile device
WO2007130416A2 (en) 2006-04-29 2007-11-15 Navio Systems, Inc. Title-enabled networking
DE102006022710A1 (de) * 2006-05-12 2007-11-15 Heidelberger Druckmaschinen Ag Serviceplattform zur Wartung von Maschinen
JP4882546B2 (ja) * 2006-06-28 2012-02-22 富士ゼロックス株式会社 情報処理システムおよび制御プログラム
US20080072053A1 (en) * 2006-09-15 2008-03-20 Halim Budi S Web-based authentication system and method
US8345272B2 (en) 2006-09-28 2013-01-01 Sharp Laboratories Of America, Inc. Methods and systems for third-party control of remote imaging jobs
US20080082626A1 (en) * 2006-09-29 2008-04-03 Microsoft Corporation Typed authorization data
US10380621B2 (en) 2006-11-15 2019-08-13 Api Market, Inc. Title-acceptance and processing architecture
JP5579073B2 (ja) * 2007-11-16 2014-08-27 トムソン ライセンシング ストリーミング・メディアのセッション管理を行なうシステムおよび方法
US9137018B2 (en) * 2007-12-19 2015-09-15 The Directv Group, Inc. Method and system for providing a generic program guide data from a primary content provider to a user network device through a partner service provider
US8453251B2 (en) * 2007-12-19 2013-05-28 The Directv Group, Inc. Method and system for securely communicating between a user network device, a primary service provider and a partner service provider
US8621646B2 (en) * 2007-12-19 2013-12-31 The Directv Group, Inc. Method and system for authenticating a user receiving device into a primary service provider system to communicate with a partner service provider
US8533852B2 (en) * 2007-12-19 2013-09-10 The Directv Group, Inc. Method and system for securely communicating between a primary service provider and a partner service provider
US20090183246A1 (en) * 2008-01-15 2009-07-16 Authlogic Inc. Universal multi-factor authentication
US8132238B2 (en) 2008-05-13 2012-03-06 Ebay Inc. System and method for identity authentication for service access without use of stored credentials
DE102008024783A1 (de) * 2008-05-23 2009-12-10 RUHR-UNIVERSITäT BOCHUM Sichere, browser-basierte Einmalanmeldung mit Clientzertifikaten
US9258286B1 (en) 2008-07-30 2016-02-09 United Services Automobile Association (Usaa) Systems and methods for communications channel authentication
US9479509B2 (en) 2009-11-06 2016-10-25 Red Hat, Inc. Unified system for authentication and authorization
US8972346B2 (en) * 2009-12-11 2015-03-03 International Business Machines Corporation Method and system for minimizing synchronization efforts of parallel database systems
US8474009B2 (en) 2010-05-26 2013-06-25 Novell, Inc. Dynamic service access
US9111079B2 (en) 2010-09-30 2015-08-18 Microsoft Technology Licensing, Llc Trustworthy device claims as a service
US9794239B1 (en) * 2011-02-18 2017-10-17 The Directv Group, Inc. Method and system for authenticating service providers to communicate with a primary service provider
US9854308B1 (en) 2011-02-18 2017-12-26 The Directv Group, Inc. Method and system for authorizing user devices to communicate with a primary service provider using a limited number of streams
US9838727B1 (en) 2011-02-18 2017-12-05 The Directv Group, Inc. Method and system for discovering an identity provider
WO2013019519A1 (en) 2011-08-02 2013-02-07 Rights Over Ip, Llc Rights-based system
US9131370B2 (en) 2011-12-29 2015-09-08 Mcafee, Inc. Simplified mobile communication device
US8819445B2 (en) * 2012-04-09 2014-08-26 Mcafee, Inc. Wireless token authentication
US9262592B2 (en) 2012-04-09 2016-02-16 Mcafee, Inc. Wireless storage device
US20130268687A1 (en) 2012-04-09 2013-10-10 Mcafee, Inc. Wireless token device
US9547761B2 (en) 2012-04-09 2017-01-17 Mcafee, Inc. Wireless token device
US8904528B2 (en) 2013-03-15 2014-12-02 Elemica, Inc. Method and apparatus for translation of business messages
US9224135B2 (en) 2013-03-15 2015-12-29 Elemica, Inc. Method and apparatus for adaptive configuration for translation of business messages
US9443229B2 (en) 2013-03-15 2016-09-13 Elemica, Inc. Supply chain message management and shipment constraint optimization
US9760501B2 (en) 2014-11-05 2017-09-12 Google Inc. In-field smart device updates
US20160128104A1 (en) * 2014-11-05 2016-05-05 Google Inc. In-field smart device updates
FR3032847A1 (fr) * 2015-02-13 2016-08-19 Orange Technique de connexion a un service
US9621355B1 (en) * 2015-10-01 2017-04-11 Cisco Technology, Inc. Securely authorizing client applications on devices to hosted services
CN106790331B (zh) * 2015-11-23 2020-07-03 腾讯科技（深圳）有限公司 一种业务接入方法、系统及相关装置
JP2017228145A (ja) * 2016-06-23 2017-12-28 株式会社リコー 認証システム、通信システム、認証認可方法、及びプログラム
US10686886B2 (en) * 2016-10-19 2020-06-16 Mirosoft Technology Licensing, LLC Establishing secure sessions for stateful cloud services
EP3334115B1 (de) 2016-12-07 2019-10-09 Swisscom AG Benutzerauthentifizierung auf einem token basierend
US10616211B2 (en) * 2017-04-12 2020-04-07 Cisco Technology, Inc. System and method for authenticating clients
US11171958B1 (en) 2018-07-10 2021-11-09 United Services Automobile Association (Usaa) Secure session sharing between computing devices
US11032270B1 (en) * 2020-04-07 2021-06-08 Cyberark Software Ltd. Secure provisioning and validation of access tokens in network environments

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5280527A (en) * 1992-04-14 1994-01-18 Kamahira Safe Co., Inc. Biometric token for authorizing access to a host system
JPH10327147A (ja) * 1997-05-21 1998-12-08 Hitachi Ltd 電子認証公証方法およびシステム
CA2295150A1 (en) * 1997-06-26 1999-01-07 Michael John Kenning Data communications
US6212635B1 (en) * 1997-07-18 2001-04-03 David C. Reardon Network security system allowing access and modification to a security subsystem after initial installation when a master token is in place
US6370139B2 (en) * 1997-10-24 2002-04-09 Tranz-Send Broadcasting Network, Inc. System and method for providing information dispersal in a networked computing environment
US6393411B1 (en) * 1998-07-21 2002-05-21 Amdahl Corporation Device and method for authorized funds transfer
US6226752B1 (en) * 1999-05-11 2001-05-01 Sun Microsystems, Inc. Method and apparatus for authenticating users
US6691232B1 (en) * 1999-08-05 2004-02-10 Sun Microsystems, Inc. Security architecture with environment sensitive credential sufficiency evaluation
FI108184B (fi) * 1999-10-12 2001-11-30 Sonera Oyj Palvelun pääsynvalvonta
AU2001251701A1 (en) * 2000-02-25 2001-09-03 Identix Incorporated Secure transaction system
US20010045451A1 (en) * 2000-02-28 2001-11-29 Tan Warren Yung-Hang Method and system for token-based authentication
US20020031230A1 (en) * 2000-08-15 2002-03-14 Sweet William B. Method and apparatus for a web-based application service model for security management
US20020078352A1 (en) * 2000-12-15 2002-06-20 International Business Machines Corporation Secure communication by modification of security codes
US20020129261A1 (en) * 2001-03-08 2002-09-12 Cromer Daryl Carvis Apparatus and method for encrypting and decrypting data recorded on portable cryptographic tokens
US7657639B2 (en) * 2006-07-21 2010-02-02 International Business Machines Corporation Method and system for identity provider migration using federated single-sign-on operation

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10511587B2 (en) 2015-06-11 2019-12-17 Siemens Aktiengesellschaft Authorization apparatus and method for an authorized issuing of an authentication token for a device

Also Published As

Publication number Publication date
NL1018494C2 (nl) 2003-01-10
WO2003007571A1 (en) 2003-01-23
US7565554B2 (en) 2009-07-21
DE60218042D1 (de) 2007-03-22
EP1405490A1 (de) 2004-04-07
ES2280553T3 (es) 2007-09-16
US20040221045A1 (en) 2004-11-04
ATE353515T1 (de) 2007-02-15
EP1405490B1 (de) 2007-02-07

Similar Documents

Publication Publication Date Title
DE60218042T2 (de) Verfahren und system für einen dienstleistungsprozess zur bereitstellung eines dienstes zu einem kunden
DE60220718T2 (de) Verfahren und system zur sicheren behandlung von elektronischen geschäften im internet
EP1777907B1 (de) Vorrichtungen und Verfahren zum Durchführen von kryptographischen Operationen in einem Server-Client-Rechnernetzwerksystem
DE60308692T2 (de) Verfahren und system für benutzerbestimmte authentifizierung und einmalige anmeldung in einer föderalisierten umgebung
DE60031755T2 (de) Verfahren und Vorrichtung für authentifizierten Zugang zu einer Mehrzahl von Netzbetreibern durch eine einzige Anmeldung
DE602004004325T2 (de) Verfahren und Vorrichtung zur Bereitstellung eines sicheren VPN-Zugriffs mittels veränderter Zertifikat-Zeichenketten
DE60313445T2 (de) Apparat und Methode für eine Authentisierung mit einmaliger Passworteingabe über einen unsicheren Netzwerkzugang
DE60215117T2 (de) Mehrbenutzeranwendungen in multimedia-netzwerken
DE602004007301T2 (de) Adressierungs-verfahren und -vorrichtung zum aufbau von hip-verbindungen zwischen gewöhnlichen und hip-fähigen netzknoten
DE102009041805A1 (de) SIP-Signalisierung ohne ständige Neu-Authentifizierung
DE102008024783A1 (de) Sichere, browser-basierte Einmalanmeldung mit Clientzertifikaten
DE102014206325A1 (de) Verteiltes Authentifizierungssystem
DE102008062984A1 (de) Prozess zur Authentifizierung eines Nutzers durch ein Zertifikat unter Verwendung eines Ausserband-Nachrichtenaustausches
EP1187415A1 (de) Verfahren zur Identifikation von Internet-Nutzern
DE60203312T2 (de) Verfahren und Vorrichtung zur Authentifizierung eines Benutzers
WO2002071350A2 (de) Verfahren zur bezahlung von entgeltpflichtigen angeboten, die über ein netz erfolgen
DE112004000125T5 (de) Gesichertes Client-Server-Datenübertragungssystem
DE60218554T2 (de) Verfahren und System zur Übertragung eines Zertifikats zwischen einem Sicherheitsmodul und einem Server
EP1776821B1 (de) System und verfahren zum sicheren anmelden in einem kommuniktionssystem mit netzwerkverbindungs- und verbindungssteuerungs-rechnern
WO2002067532A1 (de) Verfahren zur übertragung von daten, proxy-server und datenübertragungssystem
EP4179758B1 (de) Authentisierung eines kommunikationspartners an einem gerät
WO2008019916A1 (de) Verfahren zur wiederaktivierung einer sicheren kommunikationsverbindung
DE60319859T2 (de) Sicherheitsverwaltungsverfahren für eine integrierte einrichtung eines netzwerks
WO2023156285A1 (de) Zero trust für ein operational technology netzwerk transport protokoll
DE102022208754A1 (de) Authentifizierungsverfahren

Legal Events

Date Code Title Description
8364 No opposition during term of opposition