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 PDFInfo
- 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
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)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer And Data Communications (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Electrical Discharge Machining, Electrochemical Machining, And Combined Machining (AREA)
- General Factory Administration (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)
- 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.
- 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.
- 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.
- 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.
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)
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)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
FR2826811B1 (fr) * | 2001-06-27 | 2003-11-07 | France Telecom | Procede d'authentification cryptographique |
US7707121B1 (en) | 2002-05-15 | 2010-04-27 | Navio Systems, Inc. | Methods and apparatus for title structure and management |
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 |
JP4425859B2 (ja) * | 2003-07-11 | 2010-03-03 | 日本電信電話株式会社 | アドレスに基づく認証システム、その装置およびプログラム |
US20060195565A1 (en) * | 2003-08-01 | 2006-08-31 | Antoine De-Poorter | 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 |
KR101203245B1 (ko) | 2004-06-12 | 2012-11-20 | 마이크로소프트 코포레이션 | 소프트웨어 보안 |
US7552337B2 (en) | 2004-06-12 | 2009-06-23 | Microsoft Corporation | Service protection |
US7721340B2 (en) | 2004-06-12 | 2010-05-18 | Microsoft Corporation | Registry protection |
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 |
US8296562B2 (en) | 2004-07-15 | 2012-10-23 | Anakam, Inc. | Out of band system and method for authentication |
US8533791B2 (en) | 2004-07-15 | 2013-09-10 | Anakam, Inc. | System and method for second factor authentication services |
ES2420158T3 (es) | 2004-07-15 | 2013-08-22 | Anakam, Inc. | Sistema y método para bloquear un inicio de sesión de red no autorizado usando una contraseña robada |
JP2006054656A (ja) * | 2004-08-11 | 2006-02-23 | Nec Corp | Ptt通信システム、ptt通信方法、ptt通信サーバ |
JP2006086907A (ja) * | 2004-09-17 | 2006-03-30 | Fujitsu Ltd | 設定情報配布装置、方法、プログラム、媒体、及び設定情報受信プログラム |
US8006293B2 (en) * | 2004-10-08 | 2011-08-23 | Sharp Laboratories Of America, Inc. | Methods and systems for imaging device credential acceptance |
US8001183B2 (en) | 2004-10-08 | 2011-08-16 | Sharp Laboratories Of America, Inc. | Methods and systems for imaging device related event notification |
US8001587B2 (en) * | 2004-10-08 | 2011-08-16 | Sharp Laboratories Of America, Inc. | Methods and systems for imaging device credential management |
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 |
US8023130B2 (en) | 2004-10-08 | 2011-09-20 | Sharp Laboratories Of America, Inc. | Methods and systems for imaging device accounting data maintenance |
US7978618B2 (en) | 2004-10-08 | 2011-07-12 | Sharp Laboratories Of America, Inc. | Methods and systems for user interface customization |
US7920101B2 (en) | 2004-10-08 | 2011-04-05 | Sharp Laboratories Of America, Inc. | Methods and systems for imaging device display standardization |
US8018610B2 (en) | 2004-10-08 | 2011-09-13 | Sharp Laboratories Of America, Inc. | Methods and systems for imaging device remote application interaction |
US8065384B2 (en) | 2004-10-08 | 2011-11-22 | Sharp Laboratories Of America, Inc. | Methods and systems for imaging device event notification subscription |
US8120793B2 (en) * | 2004-10-08 | 2012-02-21 | Sharp Laboratories Of America, Inc. | Methods and systems for displaying content on an imaging device |
US8171404B2 (en) | 2004-10-08 | 2012-05-01 | Sharp Laboratories Of America, Inc. | Methods and systems for disassembly and reassembly of examination documents |
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 |
US8120797B2 (en) * | 2004-10-08 | 2012-02-21 | Sharp Laboratories Of America, Inc. | Methods and systems for transmitting content to an imaging device |
US8115944B2 (en) | 2004-10-08 | 2012-02-14 | Sharp Laboratories Of America, Inc. | Methods and systems for local configuration-based imaging device accounting |
US7873553B2 (en) | 2004-10-08 | 2011-01-18 | Sharp Laboratories Of America, Inc. | Methods and systems for authorizing imaging device concurrent account use |
US8125666B2 (en) | 2004-10-08 | 2012-02-28 | Sharp Laboratories Of America, Inc. | Methods and systems for imaging device document management |
US8001586B2 (en) | 2004-10-08 | 2011-08-16 | Sharp Laboratories Of America, Inc. | Methods and systems for imaging device credential management and authentication |
US8051125B2 (en) | 2004-10-08 | 2011-11-01 | Sharp Laboratories Of America, Inc. | Methods and systems for obtaining imaging device event notification subscription |
US8156424B2 (en) | 2004-10-08 | 2012-04-10 | Sharp Laboratories Of America, Inc. | Methods and systems for imaging device dynamic document creation and organization |
US8237946B2 (en) | 2004-10-08 | 2012-08-07 | Sharp Laboratories Of America, Inc. | Methods and systems for imaging device accounting server redundancy |
US8060921B2 (en) * | 2004-10-08 | 2011-11-15 | Sharp Laboratories Of America, Inc. | Methods and systems for imaging device credential authentication and communication |
US7870185B2 (en) * | 2004-10-08 | 2011-01-11 | Sharp Laboratories Of America, Inc. | Methods and systems for imaging device event notification administration |
US8006292B2 (en) * | 2004-10-08 | 2011-08-23 | Sharp Laboratories Of America, Inc. | Methods and systems for imaging device credential submission and consolidation |
US8024792B2 (en) | 2004-10-08 | 2011-09-20 | Sharp Laboratories Of America, Inc. | Methods and systems for imaging device credential submission |
US7970813B2 (en) | 2004-10-08 | 2011-06-28 | Sharp Laboratories Of America, Inc. | Methods and systems for imaging device event notification administration and subscription |
US8032608B2 (en) | 2004-10-08 | 2011-10-04 | Sharp Laboratories Of America, Inc. | Methods and systems for imaging device notification access control |
US7969596B2 (en) | 2004-10-08 | 2011-06-28 | Sharp Laboratories Of America, Inc. | Methods and systems for imaging device document translation |
US8384925B2 (en) | 2004-10-08 | 2013-02-26 | Sharp Laboratories Of America, Inc. | Methods and systems for imaging device accounting data management |
US8051140B2 (en) | 2004-10-08 | 2011-11-01 | Sharp Laboratories Of America, Inc. | Methods and systems for imaging device control |
US8115946B2 (en) | 2004-10-08 | 2012-02-14 | Sharp Laboratories Of America, Inc. | Methods and sytems for imaging device job definition |
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 |
US8049677B2 (en) | 2004-10-08 | 2011-11-01 | Sharp Laboratories Of America, Inc. | Methods and systems for imaging device display element localization |
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 |
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 |
US8115945B2 (en) | 2004-10-08 | 2012-02-14 | Sharp Laboratories Of America, Inc. | Methods and systems for imaging device job configuration management |
US7873718B2 (en) | 2004-10-08 | 2011-01-18 | Sharp Laboratories Of America, Inc. | Methods and systems for imaging device accounting server recovery |
US8032579B2 (en) | 2004-10-08 | 2011-10-04 | Sharp Laboratories Of America, Inc. | Methods and systems for obtaining imaging device notification access control |
US8035831B2 (en) | 2004-10-08 | 2011-10-11 | Sharp Laboratories Of America, Inc. | Methods and systems for imaging device remote form management |
US8015234B2 (en) | 2004-10-08 | 2011-09-06 | Sharp Laboratories Of America, Inc. | Methods and systems for administering imaging device notification access control |
US8006176B2 (en) | 2004-10-08 | 2011-08-23 | Sharp Laboratories Of America, Inc. | Methods and systems for imaging-device-based form field management |
US8060930B2 (en) | 2004-10-08 | 2011-11-15 | Sharp Laboratories Of America, Inc. | Methods and systems for imaging device credential receipt and authentication |
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 |
WO2007078987A2 (en) | 2005-12-29 | 2007-07-12 | Navio Systems, Inc. | Software, systems, and methods for processing digital bearer instruments |
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 |
CN101889438A (zh) * | 2007-11-16 | 2010-11-17 | 汤姆森特许公司 | 用于流媒体的会话管理的***和方法 |
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 |
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 |
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 |
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 |
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 |
US9838727B1 (en) | 2011-02-18 | 2017-12-05 | The Directv Group, Inc. | Method and system for discovering an identity provider |
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 |
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 |
US9547761B2 (en) | 2012-04-09 | 2017-01-17 | Mcafee, Inc. | Wireless token device |
US9262592B2 (en) | 2012-04-09 | 2016-02-16 | Mcafee, Inc. | Wireless storage device |
US8819445B2 (en) * | 2012-04-09 | 2014-08-26 | Mcafee, Inc. | Wireless token authentication |
US20130268687A1 (en) | 2012-04-09 | 2013-10-10 | Mcafee, Inc. | Wireless token device |
US9443229B2 (en) | 2013-03-15 | 2016-09-13 | Elemica, Inc. | Supply chain message management and shipment constraint optimization |
US9224135B2 (en) | 2013-03-15 | 2015-12-29 | Elemica, Inc. | Method and apparatus for adaptive configuration for translation of business messages |
US8904528B2 (en) | 2013-03-15 | 2014-12-02 | Elemica, Inc. | Method and apparatus for translation of business messages |
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)
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 |
WO2001063567A2 (en) * | 2000-02-25 | 2001-08-30 | 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 |
-
2001
- 2001-07-09 NL NL1018494A patent/NL1018494C2/nl not_active IP Right Cessation
-
2002
- 2002-06-27 EP EP02747453A patent/EP1405490B1/de not_active Expired - Lifetime
- 2002-06-27 US US10/483,374 patent/US7565554B2/en not_active Expired - Fee Related
- 2002-06-27 WO PCT/EP2002/007261 patent/WO2003007571A1/en active IP Right Grant
- 2002-06-27 AT AT02747453T patent/ATE353515T1/de not_active IP Right Cessation
- 2002-06-27 DE DE60218042T patent/DE60218042T2/de not_active Expired - Lifetime
- 2002-06-27 ES ES02747453T patent/ES2280553T3/es not_active Expired - Lifetime
Cited By (1)
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 |
---|---|
EP1405490B1 (de) | 2007-02-07 |
US20040221045A1 (en) | 2004-11-04 |
NL1018494C2 (nl) | 2003-01-10 |
US7565554B2 (en) | 2009-07-21 |
DE60218042D1 (de) | 2007-03-22 |
WO2003007571A1 (en) | 2003-01-23 |
ATE353515T1 (de) | 2007-02-15 |
ES2280553T3 (es) | 2007-09-16 |
EP1405490A1 (de) | 2004-04-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 | |
DE69830726T2 (de) | Verfahren zum betrieb eines systems von authentifizierungsservern sowie ein solches system | |
DE102009041805A1 (de) | SIP-Signalisierung ohne ständige Neu-Authentifizierung | |
DE102008024783A1 (de) | Sichere, browser-basierte Einmalanmeldung mit Clientzertifikaten | |
DE102008062984A1 (de) | Prozess zur Authentifizierung eines Nutzers durch ein Zertifikat unter Verwendung eines Ausserband-Nachrichtenaustausches | |
DE60203312T2 (de) | Verfahren und Vorrichtung zur Authentifizierung eines Benutzers | |
EP1187415A1 (de) | Verfahren zur Identifikation von Internet-Nutzern | |
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 |