DE60314871T2 - Verfahren zur authentifizierung eines anwenders bei einem zugang zu einem dienst eines diensteanbieters - Google Patents

Verfahren zur authentifizierung eines anwenders bei einem zugang zu einem dienst eines diensteanbieters Download PDF

Info

Publication number
DE60314871T2
DE60314871T2 DE60314871T DE60314871T DE60314871T2 DE 60314871 T2 DE60314871 T2 DE 60314871T2 DE 60314871 T DE60314871 T DE 60314871T DE 60314871 T DE60314871 T DE 60314871T DE 60314871 T2 DE60314871 T2 DE 60314871T2
Authority
DE
Germany
Prior art keywords
user
authentication
service provider
service
provider
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
DE60314871T
Other languages
English (en)
Other versions
DE60314871D1 (de
Inventor
Axel Busboom
Raphael Quinet
Marko Schuba
Silke Holtmanns
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.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
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 Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Application granted granted Critical
Publication of DE60314871D1 publication Critical patent/DE60314871D1/de
Publication of DE60314871T2 publication Critical patent/DE60314871T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • 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/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • 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/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105—Multiple levels of security
    • 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/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/67—Risk-dependent, e.g. selecting a security level depending on risk profiles

Description

  • TECHNISCHES GEBIET DER ERFINDUNG
  • Die vorliegende Erfindung betrifft das Gebiet der Authentifizierung, insbesondere ein Verfahren zur Authentifizierung eines Benutzers bei einem Dienst eines Diensteanbieters.
  • ALLGEMEINER STAND DER TECHNIK
  • Viele elektronisch verfügbare Dienste wie Websites im Internet oder elektronischer Handel (E-Commerce) erfordern eine Identifizierung und Authentifizierung des Benutzers für eine Reihe von Zwecken, wie das Gewähren des Zugangs zu vertraulichen Informationen oder Diensten oder Ressourcen, z.B. für webbasierten E-Mail-Zugang oder Online-Banking, wie das Anbieten von personalisierten Diensten, die an ein Benutzerprofil angepasst sind, wie Data-Mining, d.h. das Ziehen von Schlussfolgerungen aus den Interaktionen einer Vielzahl von Benutzern mit dem Dienst, z.B. zum Erzeugen von Profilen des Verhaltens eines Benutzers als Verbraucher, oder wie das Überprüfen der Kreditwürdigkeit eines Benutzers in E-Commerce-Anwendungen, z.B. indem nachgeprüft wird, ob der Benutzer immer seine Rechnungen bezahlt hat. Eine Benutzeridentifizierung und -authentifizierung kann auch erforderlich sein, um einen Zugang zu anderen Formen von Diensten zu gewähren, wie den Zugang zu physischen Einheiten wie zu Fahrzeugtüren, einem Firmengebäude oder einem Lenkrad.
  • Identifizierung bedeutet die Spezifizierung einer Kennung, welche einen bestimmten Benutzer oder eine bestimmte Gruppe von Benutzern eindeutig kennzeichnet. Die spezifizierte Kennung kann auf eine bestimmte Person oder Gruppe von Personen zurückführbar sein oder auch nicht, d.h. die Kennung könnte der Name des Benutzers im Klartext sein, sie könnte jedoch auch ein zufällig gewählter Anmeldename sein. Die einzige Bedingung ist, dass nur eine einzige Person, oder eine Person aus einer bestimmten Gruppe von Personen im Falle einer Gruppenanmeldung, unter dieser speziellen Benutzerkennung registriert sein kann, auf deren Basis die Identifizierung des registrierten Benutzers möglich ist. Ein Beispiel ist z.B. ein Anmeldename des Benutzers für den Zugang zu einem Dienst eines Diensteanbieters. Authentifizierung ist definiert als die Überprüfung einer Kennung, z.B. die Überprüfung, dass ein Benutzer, der eine gewisse Kennung präsentiert, tatsächlich derselbe Benutzer ist, der sich ursprünglich unter eben dieser Kennung registrieren ließ.
  • Eine Authentifizierung erfolgt durch das Überprüfen von User Credentials (Benutzer-Berechtigungsnachweisen). Es gibt im Wesentlichen drei Typen von User Credentials. Zuallererst etwas, was der Benutzer besitzt, z.B. ein Schlüssel, eine Chipkarte, eine Company ID Card (Firmenausweis) usw., zweitens etwas, was der Benutzer weiß, z.B. ein Passwort, eine persönliche Identifikationsnummer (PIN), der Mädchenname seiner Mutter usw., und drittens Körpermerkmale des Benutzers, z.B. Irismuster, Stimme, Fingerabdruck, Gesichtsmerkmale, Handschrift usw.
  • Eine Benutzerauthentifizierung kann in der Überprüfung eines einzigen oder mehrerer Typen von Credentials bestehen, z.B. des Passwortes allein, oder aber des Besitzes einer Company ID (Firmenkennung) in Kombination mit der Kenntnis eines PIN-Codes. Eine Benutzerkennung, z.B. ein Name des Benutzers, wird in einem Identifizierungsschritt verwendet, um User Credentials, die bei der Authentifizierung von dem Benutzer eingeholt wurden, mit den mit der Benutzerkennung verknüpften User Credentials in Bezug zu bringen, die registriert sind. Indem überprüft wird, ob die eingeholten User Credentials und die registrierten User Credentials übereinstimmen, kann die Überprüfung der Benutzerkennung und damit die Authentifizierung bewerkstelligt werden. Daher umfasst eine Authentifizierung normalerweise eine Identifizierung einer Entität, für welche eine Authentifizierung angefordert wird, als Voraussetzung, und normalerweise ist für die Authentifizierung eine Registrierung des Benutzers erforderlich.
  • In der Vergangenheit führte jeder Diensteanbieter normalerweise seine eigene Identifizierung und Authentifizierung von Benutzern durch, z.B. meist über einen Benutzernamen und ein Passwort, möglicherweise unter Verwendung eines sicheren Transportprotokolls, und er pflegte seine eigene Benutzerprofil-Datenbank. Der Nachteil für den Benutzer ist, dass er sich normalerweise für unterschiedliche Diensteanbieter verschiedene Kombinationen von Benutzerkennungen und Passwörtern, oder, allgemeiner, verschiedene Kombinationen von Benutzerkennungen und Credentials merken muss, was unpraktisch und in den meisten Fällen nicht sehr sicher ist, wenn der Benutzer seine verschiedenen Benutzerkennungen und entsprechenden jeweiligen Passwörter (Credentials) notiert. Die Sicherheit wird noch weiter beeinträchtigt, wenn der Benutzer dieselben oder ähnliche Kombinationen für verschiedene Diensteanbieter verwendet. Der Nachteil für einen Diensteanbieter ist, dass er eigene Datenbanken unterhalten muss und alle Schritte für eine Authentifizierung selbst ausführen muss. Außerdem beruht eine eigene Authentifizierung eines Diensteanbieter aus technischen und wirtschaftlichen Gründen normalerweise auf einem einzigen Typ oder einer sehr begrenzten Anzahl von Typen von User Credentials, da das Einrichten der entsprechenden Infrastruktur für das Einholen und Verarbeiten von User Credentials unterschiedlicher Typen teuer ist, was ein ernstes Hindernis für die Einführung moderner Authentifizierungsverfahren ist, wie von Verfahren, die auf Biometrik beruhen oder auf Chipkarten wie etwa einer Subscriber Identity Module (Teilnehmerkennungsmodul, SIM-) Karte in einem Mobiltelefon beruhen.
  • In jüngster Zeit ist eine Reihe von Technologien entwickelt worden, z.B. Microsoft® Passport, siehe z.B. Microsoft Passport Technical White Paper, März 2001, veröffentlicht unter http://www.passport.com, welche darauf abzielen, die Authentifizierung von dem eigentlichen Dienst zu trennen. In diesem Falle ist ein "Identitätsanbieter" (Identity Provider, "IdP") für die Benutzerregistrierung und jedes Mal, wenn der Benutzer auf einen Dienst zugreifen möchte, für die Benutzerauthentifizierung verantwortlich. Benutzerregistrierung und Benutzerauthentifizierung können in einer einzigen Entität implementiert sein oder können getrennt sein. Der Anbieter des eigentlichen Dienstes ("Diensteanbieter", Service Provider, "SP") kann mit dem Identitätsanbieter identisch sein oder auch nicht. Ein Identitätsanbieter könnte selbst als ein Anbieter bestimmter Dienste agieren und außerdem Identitätsdienste für externe Diensteanbieter anbieten. Bei Microsoft® Passport wird eine Benutzerauthentifizierung immer über einen Benutzername/Passwort-Mechanismus durchgeführt, der über SSL transportiert wird, ohne irgendwelche Einschränkungen auf das Passwortwechsel-Intervall zum Zugreifen auf einen Dienst beliebiger Art, der bei Microsoft® Passport registriert ist.
  • Die Trennung der Funktionalitäten des Identitätsanbieters und des Diensteanbieters hat eine Reihe von Vorteilen. Der Diensteanbieter muss nicht unbedingt seine eigene Benutzerregistrierung und -authentifizierung abwickeln, sondern kann diese zu dem Identitätsanbieter "auslagern". Noch wichtiger ist jedoch, dass der Benutzer eine einzige, konsistente Anmeldeprozedur für unterschiedliche Dienste nutzen kann. Wie erwähnt, müssen Benutzer gegenwärtig entweder verschiedene Credentials zur Authentifizierung für die einzelnen Diensteanbieter sich merken und/oder besitzen, oder sie verwenden Credentials wie etwa Passwörter mehrfach, was natürlich die Sicherheit beeinträchtigt. Zum Beispiel könnte ein Angreifer ein unverschlüsseltes Passwort abhören, das der Benutzer bei einem Webportal eingibt, und es dann verwenden, um zu versuchen, mit demselben Passwort Zugang zum Online-Bankkonto des Benutzers zu erhalten.
  • Die bekannte Identitätsanbieter-Lösung Microsoft® Passport unterscheidet jedoch nicht zwischen unterschiedlichen Sicherheitsanforderungen für verschiedene Dienste oder Diensteanbieter. Die Sicherheitsanforderung durch einen Diensteanbieter kann stark von den Zwecken abhängen, für welche die Authentifizierung benötigt wird. Um einfach ein personalisiertes Webportal bereitzustellen, wird normalerweise ein niedrigeres Sicherheitsniveau ausreichend sein als für einen Online-Zugang zu einem Bankkonto oder für das Authorisieren einer größeren Geldtransaktion. Dagegen betrachtet Microsoft® Passport eine Authentifizierung als eine binäre Entscheidung, wie authentifiziert sein oder nicht authentifiziert sein, auf der Basis eines einzigen Credential-Typs, und setzt voraus, dass der statische Authentifizierungsmechanismus, der auf der Kombination Benutzername-Passwort beruht, sowohl dem Identitätsanbieter als auch dem Diensteanbieter bekannt ist und, explizit oder implizit, im Voraus vereinbart worden ist. Dies hat offensichtlich eine Reihe von Nachteilen, darunter vor allem die Unfähigkeit, unterschiedlichen Typen von Sicherheitsanforderungen für verschiedene Dienste/Ressourcen Rechnung zu tragen, und die Unfähigkeit, Änderungen der Sicherheitsanforderungen, die im Laufe der Zeit eintreten, Rechnung zu tragen. Wenn ein "Passport-ähnlicher" Identitätsanbieter irgendwann beschließt, den Authentifizierungsprozess zu ändern, müsste dies jedem Diensteanbieter separat unter Verwendung von "Out-of-Band"-Mitteln mitgeteilt werden, oder der Diensteanbieter müsste einfach hoffen, dass eventuelle Änderungen, welche der Identitätsanbieter vornimmt, "sinnvoll" sind.
  • WO 01/11450 offenbart eine Systemarchitektur und ein Verfahren für eine einzige Anmeldungsauthentifizierung bei mehreren Informationsressourcen. Die Sicherheitsarchitektur verknüpft mit Informationsressourcen Vertrauenskategorie-(Trust-Level-)Anforderungen, und mit den Vertrauenskategorien sind Authentifizierungsschemata verknüpft, die auf Passwörtern, Zertifikaten, biometrischen Techniken und Chipkarten beruhen. Bei Empfang einer Anforderung für einen Zugang zu einer Informationsressource ohne vorherige Authentifizierung entsprechend einer ausreichenden Vertrauenskategorie benutzt ein zentrales Steuerelement (Gatekeeper), der zwischen der Client-Entität und den Informationsressourcen zwischengeschaltet ist, einen Credential-Einholdienst zum Erlangen eines Anmelde-Credentials für die Client-Entität entsprechend einer Abbildungsregel, welche eine Entsprechung zwischen der ausreichenden Vertrauenskategorie und einer Menge von geeigneten Credential-Typen festlegt.
  • Das System, das in WO 01/11450 A1 beschrieben ist, weist eine Reihe von Einschränkungen auf. Vor allem stützt es sich auf Verknüpfungen zwischen den Informationsressourcen und Vertrauenskategorien und auf Abbildungsregeln zwischen den Vertrauenskategorien und den für die Authentifizierung verwendeten Credential-Typen, was beides eine A-priori-Kenntnis und vorherige Übereinkunft über die Verknüpfungen und die Abbildungsregeln zwischen der Entität, welche Identitätsanbieter-Funktionalität zur Verfügung stellt, und der Informationsressource erfordert. Ferner werden alle Informationsressourcen, welche mit derselben Vertrauenskategorie verknüpft sind, auf dieselbe Weise gehandhabt. Dies führt insbesondere immer dann zu einem Problem, wenn ein Identitätsanbieter beschließt, eine Verknüpfung und/oder eine Abbildungsregel zu ändern, weil möglicherweise nicht alle Informationsressourcen (oder Anbieter der jeweiligen Informationsressourcen), die von der Änderung betroffen sind, die Änderung akzeptabel finden, z.B. aus Sicherheits-, technischen oder die Geschäftstätigkeit betreffenden Gründen. Daher bestimmt letztendlich nicht der Anbieter der Informationsressource oder die Informationsressource selbst, sondern der Identitätsanbieter den Authentifizierungsprozess, d.h. er bestimmt, welche speziellen Credentials für eine bestimmte Authentifizierung zu verwenden sind.
  • Richtlinienentscheidungen dieser Art, die von einem Identitätsanbieter getroffen werden, sind jedoch für viele Diensteanbieter nicht akzeptabel. Eine Aktualisierung von Verknüpfungen oder Abbildungsregeln kann daher Konflikte mit den Diensteanbietern zur Folge haben. Statische oder vordefinierte Verknüpfungen oder Abbildungsregeln sind nicht genügend flexibel, um die Anforderungen der beteiligten Entitäten zu bedienen. Außerdem ist es recht kompliziert, alle möglichen Kombinationen von Authentifizierungsschemata und Credential-Typen durch vordefinierte Verknüpfungen oder Abbildungsregeln auszudrücken, um die verschiedenartigen Sicherheitsanforderungen für alle Diensteanbieter und Diensttypen zu befriedigen, insbesondere in Anbetracht der zunehmenden Menge und Vielfalt von Authentifizierungsverfahren und der sich manchmal schnell ändernden Anforderungen der Diensteanbieter. Aufgrund der inhärenten Inflexibilität von vorgegebenen Verknüpfungen oder Abbildungsregeln für eine so große Vielfalt von Möglichkeiten müssen, falls es überhaupt möglich ist, mühselige Verfahren zur Aktualisierung von Verknüpfungen oder Abbildungsregeln ausgeführt werden, bevor eine Authentifizierung entsprechend einer neuen Sicherheitsanforderung erfolgen kann. Diese Inflexibilität ist insbesondere in Ad-hoc-Situationen ein Nachteil, z.B. wenn ein Zugang zu einem z.B. neu eingeführten Dienst angefordert wird, der mit keiner oder keiner gültigen Vertrauenskategorie verknüpft ist. Eine weitere Einschränkung ist, dass der gesamte Informationsfluss, der Anforderungen und Antworten während einer Session zwischen dem Client und der Informationsressource, auf die zugegriffen wird, beinhaltet, über den Gatekeeper als eine im Pfad angeordnete Komponente verläuft. Die Verwendung eines Identitätsanbieters als eine im Pfad angeordnete Komponente für den gesamten Informationsfluss zwischen einem Benutzer-Client und dem Diensteanbieter erhöht jedoch unnötig die Last für den Identitätsanbieter.
  • Eine weitere Einschränkung, die Microsoft® Passport und WO 01/11450 A1 gemeinsam ist, ist die, dass ein einziger Identitätsanbieter für Authentifizierungszwecke verwendet wird. Diese Einschränkung zwingt Benutzer und Diensteanbieter, einem einzigen Identitätsanbieter zu vertrauen. Eine zentralisierte Authentifizierungsinstanz ist jedoch für Benutzer und Diensteanbieter aus Vertraulichkeits-, Vertrauens-, Geschäfts- oder Kostengründen oft nicht akzeptabel. Zum Beispiel möchte ein Benutzer möglicherweise nicht, dass benutzerbezogene Informationen, wie verschiedene Typen von Credentials, bei einem einzigen Identitätsanbieter gesammelt werden, um eine unnötige Datenaggregation oder gar einen Betrug zu verhindern.
  • Die Patentanmeldung US 2001/037469 A1 offenbart ein Authentifizierungsverfahren zum Auslagern der Authentifizierung von einem Anwendungsserver zu einem Anmeldeserver. Das Verfahren zur Authentifizierung beinhaltet die Schritte des Anforderns eines Zugangs für den Client zu Informationen vom Anwendungsserver, das Anfordern einer Authentifizierung des Clients durch einen Anmeldeserver und das Authentifizieren des Clients, z.B. anhand eines Benutzernamens und eines Passwortes. Nach der Authentifizierung kann der Anwendungsserver direkt mit dem Anmeldeserver kommunizieren, um zu überprüfen, ob die Authentifizierung durchgeführt worden ist.
  • Kurzdarstellung der Erfindung
  • Eine Aufgabe der vorliegenden Erfindung ist es, Verfahren, Vorrichtungen und Computerprogramme bereitzustellen, welche eine Authentifizierung eines Benutzers bei einem Dienst eines Diensteanbieters auf eine sicherere und flexiblere Art und Weise vorsehen.
  • Diese Aufgabe wird durch die Verfahren gelöst, die in den Ansprüchen 1 und 8 beschrieben sind. Ferner wird die Erfindung durch Vorrichtungen verkörpert, die durch die Ansprüche 14, 19, 25 und 31 beschrieben sind, und durch Computerprogramme, die in den Ansprüchen 33 und 34 beschrieben sind. Vorteilhafte Ausführungsformen sind in den weiteren Ansprüchen beschrieben.
  • Es wird ein Verfahren für eine Authentifizierung eines Benutzers bei einem Dienst eines Diensteanbieters offenbart.
  • Das Verfahren kann starten, indem ein Zugang für den Benutzer zu dem Dienst des Diensteanbieters angefordert wird. Die Anforderung kann von einer Vorrichtung des Benutzers zu dem Diensteanbieter gesendet werden, wobei sie den Diensteanbieter ansteuert, mit den folgenden Schritten fortzufahren. Stattdessen kann die Anforderung auch vorkonfiguriert sein und den Diensteanbieter z.B. zu vordefinierten Zeitpunkten oder Intervallen erreichen.
  • Angesteuert durch die Anforderung eines Zugangs wählt der Diensteanbieter ein oder mehrere Authentifizierungs-Sicherheitsprofile zum Spezifizieren einer Authentifizierungs-Sicherheitsanforderung für die Authentifizierung des Benutzers bei dem Dienst aus.
  • Das Verfahren wird fortgesetzt mit dem Senden einer Angabe des einen oder der mehreren ausgewählten Authentifizierungs-Sicherheitsprofile und einer Benutzerkennung, die den Benutzer identifiziert, an einen Identitätsanbieter zum Anfordern der Authentifizierung des Benutzers durch den Identitätsanbieter, d.h. der Diensteanbieter sendet von seiner zugehörigen Vorrichtung oder einer Vorrichtung, auf die durch den Diensteanbieter zugegriffen werden kann, z.B. mittels Fernzugriff, das eine oder die mehreren ausgewählten Authentifizierungs-Sicherheitsprofile als eine Form einer Angabe, um dem Identitätsanbieter die Authentifizierungs-Sicherheitsanforderung in der Form eines oder mehrerer Authentifizierungs-Sicherheitsprofile anzuzeigen, unter denen dasjenige ist, auf dessen Basis die Authentifizierung auszuführen ist. Außerdem wird die Benutzerkennung an die Identitätsanbieter gesendet, zum Zwecke einer Identifizierung des Benutzers für den Authentifizierungsschritt.
  • Anschließend wird auf der Basis der Benutzerkennung und eines des einen oder der mehreren ausgewählten Authentifizierungs-Sicherheitsprofile der Benutzer durch den Identitätsanbieter authentifiziert. Die Authentifizierung kann vorgenommen werden, indem der Benutzer identifiziert wird, z.B. als zuvor bei dem Identitätsanbieter registriert, und indem der Benutzer anhand der Benutzerkennung entsprechend dem einen Authentifizierungs-Sicherheitsprofil überprüft wird.
  • Schließlich kann die Information über ein Ergebnis der Authentifizierung durch den Identitätsanbieter an den Diensteanbieter gesendet werden. Insbesondere wird eine Assertion, welche die Authentifizierung des Benutzers anzeigt, an den Diensteanbieter gesendet, z.B. um anzuzeigen, dass die Authentifizierung des Benutzers entsprechend der Authentifizierungs-Sicherheitsanforderung vorgenommen worden ist, die durch das Authentifizierungs-Sicherheitsprofil durch den Diensteanbieter spezifiziert ist. In Abhängigkeit von der Implementierung oder dem Anwendungsfall kann die Assertion z.B. das eine Authentifizierungsprofil spezifizieren, das für die Authentifizierung verwendet wurde, oder einfach "Authentifizierung erfolgreich" anzeigen. Es sind auch andere Implementierungen für die Assertion möglich.
  • Das Verfahren verbessert die Authentifizierung eines Benutzers bei einem Dienst eines Diensteanbieters und macht das Verfahren insbesondere sehr sicher für den Diensteanbieter, da der Diensteanbieter und nicht der Identitätsanbieter letztendlich die Sicherheitsanforderung bestimmt, die von dem Identitätsanbieter für die Authentifizierung des Benutzers entsprechend einem der Authentifizierungs-Sicherheitsprofile, das von dem Diensteanbieter gewählt wurde, erfüllt werden muss. Das Verfahren ist außerdem sicherer für den Identitätsanbieter, da er klar und spontan instruiert werden kann, welche Authentifizierungsanforderung des Diensteanbieters gegenwärtig zutrifft und für die aktuelle Authentifizierung des Benutzers erfüllt werden muss. Die Authentifizierungs-Sicherheitsanforderung des Diensteanbieters kann sich ändern. In diesem Falle kann sich der Diensteanbieter umgehend an seine geänderte Sicherheitsanforderung anpassen, indem er ein anderes Authentifizierungs-Sicherheitsprofil wählt, wodurch das Verfahren sicherer gemacht wird, jedoch auch sehr flexibel für den Diensteanbieter. Daher kann insbesondere in Ad-hoc-Szenarien, jedoch auch in weiteren Situationen und Umgebungen mit sich ändernden Authentifizierungs-Sicherheitsanforderungen für den Diensteanbieter, der Diensteanbieter flexibel agieren und kann umgehend seine geänderte Authentifizierungsanforderung durch ein oder mehrere ausgewählte Authentifizierungsprofile spezifizieren und an den Identitätsanbieter übermitteln, wenn er eine Authentifizierung von dem Identitätsanbieter anfordert. Ferner erfordert das Verfahren nicht, dass der Diensteanbieter einen bestimmten, einzigen Identitätsanbieter verwendet. Stattdessen kann ein beliebiger Identitätsanbieter für die Authentifizierung verwendet werden. Außerdem ist es nicht erforderlich, dass der Identitätsanbieter als eine im Pfad angeordnete Komponente zwischen dem Diensteanbieter und dem Client angeordnet ist.
  • Gemäß einer bevorzugten Ausführungsform umfasst das eine oder umfassen die mehreren Authentifizierungs-Sicherheitsprofile wenigstens ein Sicherheitsattribut um z.B. die Authentifizierungs-Sicherheitsanforderung genauer zu spezifizieren. Der Diensteanbieter kann durch Spezifizieren von Sicherheitsattributen ein oder mehrere Authentifizierungs-Sicherheitsprofile zusammenstellen. Indem er seine eigene Spezifizierung vornimmt, kann der Diensteanbieter ein Authentifizierungs-Sicherheitsprofil maßgeschneidert exakt für seine Sicherheitsanforderung erstellen. Der Diensteanbieter kann stattdessen oder zusätzlich auch ein vordefiniertes Authentifizierungs-Sicherheitsprofil auswählen, das ein oder mehrere Sicherheitsattribute umfasst, die in einer vordefinierten Weise angeordnet sind. Authentifizierungsfähigkeiten des Identitätsanbieters und/oder des Benutzers können berücksichtigt werden, wenn ein Authentifizierungs-Sicherheitsprofil auf der Basis eines oder mehrerer Sicherheitsattribute spezifiziert und/oder ausgewählt wird. Beispiele für ein Sicherheitsattribut sind eine Spezifikation, die ein Element aus einer Gruppe beschreibt, die enthält: ein Credential, eine Transportschicht-Sicherheit, eine Vermittlungsschicht-Sicherheit, eine Sicherungsschicht-Sicherheit, Taktinformationen, Richtlinien, eine Betrugserkennungs-Maßnahme, eine Haftung und/oder Garantie und andere Sicherheitsmerkmale. Das Sicherheitsattribut kann eine Spezifikation eines Typs umfassen, z.B. eines Credential-Typs wie Passwort oder Biometrik, und eine Spezifikation eines mit einem bestimmten Typ verknüpften Wertes, z.B. eine Passwortlänge, die mit einem Passwort verknüpft ist, oder einen Fingerabdruck von einer gewissen Auflösung, der mit Biometrik verknüpft ist. Unter Verwendung von Sicherheitsattributen kann der Identitätsanbieter von dem Diensteanbieter genau instruiert werden, auf der Basis welcher Sicherheitsmerkmale gemäß den Anforderungen des Diensteanbieters die Authentifizierung des Benutzers von dem Identitätsanbieter durchzuführen ist.
  • Gemäß einer anderen bevorzugten Ausführungsform wählt der Diensteanbieter das eine oder die mehreren Authentifizierungs-Sicherheitsprofile aus einer Gruppe aus einem oder mehreren Sicherheitsprofilen aus, für welche angegeben ist, dass sie von dem Identitätsanbieter für die Authentifizierung unterstützt werden. Ein Auswählen des einen oder der mehreren Authentifizierungs-Sicherheitsprofile aus einer Gruppe aus einem oder mehreren unterstützten Authentifizierungs-Sicherheitsprofilen erhöht die Wahrscheinlichkeit für eine erfolgreiche Authentifizierung.
  • Gemäß einer anderen bevorzugten Ausführungsform empfängt der Diensteanbieter eine Angabe für die Gruppe des einen oder der mehreren unterstützten Sicherheitsprofile von dem Identitätsanbieter, z.B. durch Senden einer Liste von unterstützten Authentifizierungs-Sicherheitsprofilen. Die Angabe kann auch eine URI sein, die auf einen Server zeigt, von welchem der Diensteanbieter die Gruppe erhalten, z.B. herunterladen kann. Es sind auch andere Arten der Angabe möglich. Vorzugsweise wird die Angabe für die Gruppe oder die Gruppe selbst, als eine Form einer Angabe, zu dem Diensteanbieter gesendet, wenn Änderungen in den Authentifizierungs-Fähigkeiten des Identitätsanbieters eintreten, z.B. wenn der Identitätsanbieter ein gewisses Sicherheitsattribut wie einen Credential-Typ und/oder Credential-Wert aufhört zu unterstützen, z.B. wenn eine Passwortlänge von weniger als 4 Zeichen nicht mehr unterstützt wird, oder wenn der Identitätsanbieter einen neu eingeführten Credential-Typ oder -Wert anbietet, z.B. Fingerabdrücke, der von nun an unterstützt wird.
  • Gemäß einer anderen bevorzugten Ausführungsform wird das besagte eine Authentifizierungs-Sicherheitsprofil, auf dessen Basis die Authentifizierung durchgeführt wird, von dem Identitätsanbieter aus dem einen oder den mehreren ausgewählten Authentifizierungs-Sicherheitsprofilen ausgewählt. Indem er dies tut, kann der Identitätsanbieter vermeiden, den Diensteanbieter zu fragen, auf der Basis welches der ausgewählten Authentifizierungs-Sicherheitsprofile die Authentifizierung durchzuführen ist. Stattdessen kann der Identitätsanbieter annehmen, dass sämtliche ausgewählten und angegebenen Authentifizierungs-Sicherheitsprofile der Authentifizierungs-Sicherheitsanforderung des Diensteanbieters genügen, und kann dasjenige auswählen, das am besten passt, z.B. zu den Erfordernissen oder Fähigkeiten des Identitätsanbieters und/oder des Benutzers, welcher authentifiziert werden muss. Ferner kann die Interaktion zwischen dem Diensteanbieter und dem Identitätsanbieter zum Aushandeln des Authentifizierungs-Sicherheitsprofils, auf dessen Basis die Authentifizierung des Benutzers tatsächlich durchgeführt wird, auf ein Minimum begrenzt werden, und somit kann die Geschwindigkeit und Wahrscheinlichkeit einer erfolgreichen Authentifizierung erhöht werden.
  • Gemäß einer anderen bevorzugten Ausführungsform kann das eine oder können die mehreren ausgewählten Authentifizierungs-Sicherheitsprofile durch eine oder mehrere Relationen zu einem oder mehreren weiteren Authentifizierungs-Sicherheitsprofilen in Beziehung gesetzt werden. Jede dieser Relationen drückt ein Ordnen des einen oder der mehreren ausgewählten Authentifizierungs-Sicherheitsprofile in Bezug auf das eine oder die mehreren weiteren Authentifizierungs-Sicherheitsprofile hinsichtlich einer Stärke der Authentifizierungssicherheit aus. Beispiele für Relationen sind gerichtete Kanten, die z.B. eine Relation "stärker als oder gleich stark wie" zwischen zwei Authentifizierungs-Sicherheitsprofilen ausdrücken. Ausgewählte Authentifizierungs-Sicherheitsprofile können auch miteinander in Beziehung gesetzt werden. Auf der Basis der Relation des einen oder der mehreren ausgewählten Authentifizierungs-Sicherheitsprofile zu dem einen oder den mehreren weiteren Authentifizierungs-Sicherheitsprofilen, d.h. der Informationen über die Gesamtheit der ausgewählten und der weiteren Authentifizierungsprofile und der jeweiligen Relationen, kann der Schritt des Authentifizierens des Benutzers auf der Basis eines des einen oder der mehreren ausgewählten Authentifizierungs-Sicherheitsprofile ausgeführt werden, indem durch den Identitätsanbieter eines des einen oder der mehreren weiteren Authentifizierungs-Sicherheitsprofile ausgewählt wird, das hinsichtlich der Stärke der Authentifizierungssicherheit in einer Relation "gleich stark oder stärker" zu dem einen oder den mehreren ausgewählten Authentifizierungs-Sicherheitsprofilen steht, und indem der Benutzer auf der Basis des weiteren Authentifizierungs-Sicherheitsprofils authentifiziert wird, das von dem Identitätsanbieter gewählt wurde. Damit werden die Vielfalt und die Anzahl der Authentifizierungs-Sicherheitsprofile, die der Authentifizierungs-Sicherheitsanforderung des Diensteanbieters genügen, vergrößert. Aus der vergrößerten Vielfalt und Anzahl der Authentifizierungs-Sicherheitsprofile kann der Identitätsanbieter flexibel ein Authentifizierungsprofil für die Authentifizierung auswählen, z.B. eines, welches am besten zu gewissen Fähigkeiten passt, wie weiter oben erläutert, womit die Möglichkeit für eine erfolgreiche Authentifizierung verbessert und die Geschwindigkeit der Authentifizierung erhöht wird.
  • Gemäß einer anderen bevorzugten Ausführungsform kann der Diensteanbieter die eine oder mehreren Relationen zu dem einen oder den mehreren weiteren Authentifizierungs-Sicherheitsprofilen spezifizieren, und der Diensteanbieter kann eine Angabe der einen oder mehreren Relationen zu dem einen oder den mehreren weiteren Authentifizierungs-Sicherheitsprofilen an den Identitätsanbieter senden. Infolgedessen widerspiegeln die Relationen zwischen dem einen oder den mehreren ausgewählten und der einen oder den mehreren weiteren Authentifizierungs-Sicherheitsprofilen genauer die Authentifizierungs-Sicherheitsanforderung des Diensteanbieters, was zu einer schnelleren Authentifizierung mit weniger Interaktion für die Aushandlung eines Authentifizierungs-Sicherheitsprofils, das tatsächlich für die Authentifizierung verwendet werden soll, führen kann.
  • Gemäß einer anderen bevorzugten Ausführungsform wird die Assertion durch eine Angabe des Authentifizierungs-Sicherheitsprofils ergänzt, auf dessen Basis die Authentifizierung durchgeführt wird, und das angegebene Authentifizierungs-Sicherheitsprofil wird von dem Diensteanbieter auf Akzeptanz geprüft. Das Liefern von Informationen über das Authentifizierungs-Sicherheitsprofil, auf dessen Basis die Authentifizierung durchgeführt wird, an den Diensteanbieter erhöht die Sicherheit für den Diensteanbieter zusätzlich und verschafft dem Diensteanbieter die Möglichkeit, z.B. zu prüfen, ob das Authentifizierungs-Sicherheitsprofil, das für die Authentifizierung tatsächlich verwendet worden ist, seiner aktuellen Authentifizierungs-Sicherheitsanforderung genügt.
  • Es wird ein Verfahren zur Authentifizierung eines Benutzers bei einem Dienst eines Diensteanbieters offenbart. Das Verfahren umfasst die Schritte des Anforderns eines Zugangs für den Benutzer zu dem Dienst des Diensteanbieters, des Sendens einer Benutzerkennung, die den Benutzer identifiziert, an einen Identitätsanbieter zum Anfordern der Authentifizierung des Benutzers durch den Identitätsanbieter, des Authentifizierens des Benutzers auf der Basis der Benutzerkennung und eines Authentifizierungs-Sicherheitsprofils, des Sendens einer Assertion, welche die Authentifizierung des Benutzers anzeigt, an den Diensteanbieter, wobei die Assertion durch eine Angabe des Authentifizierungs-Sicherheitsprofils ergänzt wird, und des Prüfens des angegebenen Authentifizierungs-Sicherheitsprofils durch den Diensteanbieter auf Akzeptanz.
  • Hier übermittelt der Diensteanbieter dem Identitätsanbieter seine Authentifizierungs-Sicherheitsanforderung nicht vor der Authentifizierung, was für manche Implementierungen vorteilhaft sein kann. Der Diensteanbieter ist jedoch nach wie vor in der Lage zu überprüfen, ob die Authentifizierung des Benutzers bei dem Dienst den Authentifizierungs-Sicherheitsanforderungen des Diensteanbieters genügt, indem er prüft, ob das angegebene Authentifizierungs-Sicherheitsprofil, auf dessen Basis die Authentifizierung des Benutzers erfolgt, der Sicherheitsanforderung des Diensteanbieters entspricht. Ferner kann die Flexibilität für den Identitätsanbieter aufgrund der Tatsache erhöht werden, dass eine Authentifizierung auf der Basis eines beliebigen Authentifizierungs-Sicherheitsprofils, das von dem Identitätsanbieter unterstützt wird, für die Authentifizierung verwendet werden kann, vorzugsweise angepasst an die Authentifizierungsfähigkeiten des Benutzers, falls eine Credential-Überprüfung notwendig ist. Letztendlich ist es der Diensteanbieter, welcher befugt ist zu entscheiden, ob ein Benutzer ausreichend authentifiziert ist oder nicht.
  • Beide Verfahren können ferner den Schritt des Empfangens der Benutzerkennung und eines Verweises auf den Identitätsanbieter von einer Benutzervorrichtung, in Reaktion auf eine von dem Diensteanbieter an die Benutzervorrichtung gesendete Authentifizierungsaufforderung, bei dem Diensteanbieter umfassen. Diese Interaktion mit der Benutzervorrichtung ist sehr verbreitet und kann die Implementierung erleichtern.
  • Auf der Basis der empfangenen Assertion kann der Zugang zu dem Dienst gewährt werden. Stattdessen kann der Zugang zu dem Dienst auch auf der Basis der Assertion und auf der Basis der Prüfung auf Akzeptanz gewährt werden, d.h. indem geprüft wird, ob das angegebene Authentifizierungs-Sicherheitsprofil der Authentifizierungs-Sicherheitsanforderung des Diensteanbieters genügt, wodurch die Sicherheit der Authentifizierung insbesondere für den Diensteanbieter erhöht wird.
  • Gemäß einer anderen bevorzugten Ausführungsform kann das Verfahren einen Schritt einer Authentifizierungserweiterung umfassen. Die Authentifizierungserweiterung kann durchgeführt werden, indem eine weitere Authentifizierung auf der Basis des weiteren Authentifizierungs-Sicherheitsprofils ausgeführt wird. Die Auswahl und die weitere Authentifizierung können gemäß irgendeinem der die Auswahl und die Authentifizierung betreffenden Schritte des Verfahrens zur Authentifizierung des Benutzers bei dem Dienst des Diensteanbieters, das weiter oben beschrieben wurde, durchgeführt werden, z.B. kann der Diensteanbieter ein oder mehrere Authentifizierungs-Sicherheitsprofile auswählen und diese an den Identitätsanbieter senden, welcher eines von ihnen für die Authentifizierung des Benutzers auswählt. Der Identitätsanbieter kann ein Authentifizierungs-Sicherheitsprofil auf der Basis von Relationen auswählen und kann ein ausgewähltes Authentifizierungs-Sicherheitsprofil, auf dessen Basis die Authentifizierung durchgeführt wird, dem Diensteanbieter angeben, welcher z.B. das angegebene Authentifizierungs-Sicherheitsprofil im Hinblick darauf prüfen kann, ob es seiner Authentifizierungs-Sicherheitsanforderung für die Authentifizierung genügt. Die Erweiterungs-Funktionalität kann den Benutzer und den Diensteanbieter in die Lage versetzen, eine Sitzung fortzusetzen, wenn auf einen Dienst mit einer höheren Authentifizierungs-Sicherheitsanforderung zugegriffen werden soll.
  • Gemäß einer anderen bevorzugten Ausführungsform kann die Authentifizierungserweiterung einen Wechsel zu einem weiteren Identitätsanbieter zum Durchführen der weiteren Authentifizierung des Benutzers auf der Basis des weiteren Authentifizierungs-Sicherheitsprofils umfassen, womit sie z.B. ermöglicht, die Dienstsitzung fortzusetzen, falls der vorhergehende Identitätsanbieter das weitere Authentifizierungsprofil gemäß der stärkeren Authentifizierungs-Sicherheitsanforderung des Diensteanbieters nicht unterstützen kann.
  • Die Erfindung wird ferner durch Vorrichtungen verkörpert. Im Folgenden werden eine Vorrichtung, die einem Diensteanbieter zugeordnet ist, und eine Vorrichtung, die einem Identitätsanbieter zugeordnet ist, beschrieben.
  • Es wird eine Vorrichtung offenbart, die einem Diensteanbieter zugeordnet ist. Die dem Diensteanbieter zugeordnete Vorrichtung umfasst eine Empfangseinheit zum Empfangen von Nachrichten, eine Sendeeinheit zum Senden von Nachrichten und eine Verarbeitungseinheit zum Verarbeiten von Nachrichten und Informationen. Die dem Diensteanbieter zugeordnete Vorrichtung kann in der Lage sein, eine Anforderung eines Zugangs eines Benutzers zu einem Dienst des Diensteanbieters zu empfangen, ein oder mehrere Authentifizierungs-Sicherheitsprofile zum Spezifizieren einer Authentifizierungs-Sicherheitsanforderung für eine Authentifizierung des Benutzers bei dem Dienst auszuwählen, eine Angabe des einen oder der mehreren ausgewählten Authentifizierungs-Sicherheitsprofile und eine Benutzerkennung, die den Benutzer identifiziert, an einen Identitätsanbieter zum Anfordern der Authentifizierung des Benutzers durch den Identitätsanbieter zu senden, und eine Assertion zu empfangen, welche die Authentifizierung des Benutzers durch den Identitätsanbieter anzeigt.
  • Gemäß einer bevorzugten Ausführungsform kann die dem Diensteanbieter zugeordnete Vorrichtung in der Lage sein, das eine oder die mehreren Authentifizierungs-Sicherheitsprofile auszuwählen, die wenigstens ein Sicherheitsattribut zum Spezifizieren der Authentifizierungs-Sicherheitsanforderung umfassen.
  • Gemäß einer anderen bevorzugten Ausführungsform kann die dem Diensteanbieter zugeordnete Vorrichtung in der Lage sein, das eine oder die mehreren Authentifizierungs-Sicherheitsprofile aus einer Gruppe von Sicherheitsprofilen auszuwählen, für welche angegeben ist, dass sie von dem Identitätsanbieter für die Authentifizierung unterstützt werden.
  • Gemäß einer anderen bevorzugten Ausführungsform kann die dem Diensteanbieter zugeordnete Vorrichtung in der Lage sein, eine Angabe für die Gruppe des einen oder der mehreren unterstützten Sicherheitsprofile von dem Identitätsanbieter zu empfangen.
  • Gemäß einer anderen bevorzugten Ausführungsform kann die dem Diensteanbieter zugeordnete Vorrichtung in der Lage sein, das eine oder die mehreren ausgewählten Authentifizierungs-Sicherheitsprofile zu einer oder mehreren weiteren Authentifizierungs-Sicherheitsprofilen in Beziehung zu setzen, wobei jede Relation ein Ordnen des einen oder der mehreren ausgewählten Authentifizierungs-Sicherheitsprofile in Bezug auf das eine oder die mehreren weiteren Authentifizierungs-Sicherheitsprofile hinsichtlich einer Stärke der Authentifizierungssicherheit ausdrückt, und die Vorrichtung kann ferner in der Lage sein, wenigstens die eine oder die mehreren Relationen zu dem einen oder den mehreren weiterem Authentifizierungs-Sicherheitsprofilen, die in einer Relation "gleich stark oder stärker" hinsichtlich der Stärke der Authentifizierungssicherheit stehen, an den Identitätsanbieter für die Authentifizierung zu senden.
  • Gemäß einer anderen bevorzugten Ausführungsform kann die dem Diensteanbieter zugeordnete Vorrichtung in der Lage sein, eine Angabe des Authentifizierungs-Sicherheitsprofils zu empfangen, auf dessen Basis die Authentifizierung des Benutzers durch den Identitätsanbieter ausgeführt wird, und die Vorrichtung ist ferner in der Lage, das angegebene Authentifizierungs-Sicherheitsprofil auf Akzeptanz zu prüfen.
  • Stattdessen oder zusätzlich kann die dem Diensteanbieter zugeordnete Vorrichtung in der Lage sein, eine Anforderung eines Zugangs eines Benutzers zu einem Dienst des Diensteanbieters zu empfangen, eine Benutzerkennung, die den Benutzer identifiziert, an einen Identitätsanbieter zum Anfordern einer Authentifizierung des Benutzers durch den Identitätsanbieter zu senden, eine Assertion, welche die Authentifizierung des Benutzers anzeigt, von dem Identitätsanbieter zu empfangen, wobei die Assertion durch eine Angabe des Authentifizierungs-Sicherheitsprofils ergänzt wird, und das angegebene Authentifizierungs-Sicherheitsprofil auf Akzeptanz zu prüfen.
  • Gemäß einer anderen bevorzugten Ausführungsform kann die dem Diensteanbieter zugeordnete Vorrichtung in der Lage sein, von einer Benutzervorrichtung in Reaktion auf eine von der dem Diensteanbieter zugeordneten Vorrichtung an die Benutzervorrichtung gesendete Authentifizierungsaufforderung die Benutzerkennung und einen Verweis auf den Identitätsanbieter zu empfangen.
  • Gemäß einer anderen bevorzugten Ausführungsform kann die dem Diensteanbieter zugeordnete Vorrichtung in der Lage sein, auf der Basis der Assertion einen Zugang zu dem Dienst zu gewähren.
  • Gemäß einer anderen bevorzugten Ausführungsform kann die dem Diensteanbieter zugeordnete Vorrichtung in der Lage sein, auf der Basis der Assertion und der Prüfung auf Akzeptanz einen Zugang zu dem Dienst zu gewähren.
  • Gemäß einer anderen bevorzugten Ausführungsform kann die dem Diensteanbieter zugeordnete Vorrichtung in der Lage sein, eine Authentifizierungserweiterung auszuführen, die auf einer weiteren Authentifizierung auf der Basis eines weiteren Authentifizierungs-Sicherheitsprofils beruht.
  • Gemäß einer anderen bevorzugten Ausführungsform kann die dem Diensteanbieter zugeordnete Vorrichtung in der Lage sein, für die Authentifizierungserweiterung zu einem weiteren Identitätsanbieter zum Durchführen der weiteren Authentifizierung zu wechseln.
  • Es wird eine Vorrichtung offenbart, die einem Identitätsanbieter zugeordnet ist. Die dem Identitätsanbieter zugeordnete Vorrichtung umfasst eine Empfangseinheit zum Empfangen von Nachrichten, eine Sendeeinheit zum Senden von Nachrichten und eine Verarbeitungseinheit zum Verarbeiten von Nachrichten und Informationen. Die dem Identitätsanbieter zugeordnete Vorrichtung kann in der Lage sein, eine Aufforderung zur Authentifizierung eines Benutzers zu empfangen. Die Aufforderung umfasst eine Benutzerkennung, die den Benutzer für den Identitätsanbieter identifiziert, z.B. für die dem Identitätsanbieter zugeordnete Vorrichtung, und eine Angabe eines oder mehrerer Authentifizierungs-Sicherheitsprofile, die eine Authentifizierungs-Sicherheitsanforderung des Diensteanbieters für die Authentifizierung des Benutzers bei einem Dienst des Diensteanbieters spezifizieren. Die dem Identitätsanbieter zugeordnete Vorrichtung kann in der Lage sein, den Benutzer auf der Basis der Benutzerkennung und eines des einen oder der mehreren Authentifizierungs-Sicherheitsprofile zu authentifizieren und eine Assertion, welche dem Diensteanbieter die Authentifizierung des Benutzers anzeigt, zu senden.
  • Gemäß einer bevorzugten Ausführungsform kann die dem Identitätsanbieter zugeordnete Vorrichtung in der Lage sein, den Benutzer anhand wenigstens eines Sicherheitsattributes zu authentifizieren, das in dem einen Authentifizierungs-Sicherheitsprofil enthalten ist, auf dessen Basis die Authentifizierung durchgeführt wird.
  • Gemäß einer anderen bevorzugten Ausführungsform kann die dem Identitätsanbieter zugeordnete Vorrichtung in der Lage sein, eine Angabe für eine Gruppe von einem oder mehreren Sicherheitsprofilen, welche für die Authentifizierung von dem Identitätsanbieter unterstützt werden, an den Diensteanbieter zu senden.
  • Gemäß einer anderen bevorzugten Ausführungsform kann die dem Identitätsanbieter zugeordnete Vorrichtung in der Lage sein, das eine Authentifizierungs-Sicherheitsprofil, auf dessen Basis die Authentifizierung ausgeführt wird, aus dem einen oder den mehreren Authentifizierungs-Sicherheitsprofilen auszuwählen.
  • Ein oder mehrere Authentifizierungs-Sicherheitsprofile können durch eine oder mehrere Relationen zu einem oder mehreren weiteren Authentifizierungs-Sicherheitsprofilen in Beziehung gesetzt werden. Jede der einen oder mehreren Relationen drückt ein Ordnen des einen oder der mehreren Authentifizierungs-Sicherheitsprofile in Bezug auf das eine oder die mehreren weiteren Authentifizierungs-Sicherheitsprofile hinsichtlich einer Stärke der Authentifizierung aus. Die dem Identitätsanbieter zugeordnete Vorrichtung kann in der Lage sein, die Authentifizierung des Benutzers durch Auswählen eines des einen oder der mehreren weiteren Authentifizierungs-Sicherheitsprofile, das hinsichtlich der Stärke der Authentifizierungssicherheit in einer Relation "gleich stark oder stärker" zu dem einen oder den mehreren Authentifizierungs-Sicherheitsprofilen steht, und durch Authentifizieren des Benutzers auf der Basis des ausgewählten weiteren Authentifizierungs-Sicherheitsprofils auszuführen.
  • Gemäß einer anderen bevorzugten Ausführungsform kann die dem Identitätsanbieter zugeordnete Vorrichtung in der Lage sein, eine Angabe für die eine oder die mehreren Relationen zu dem einen oder den mehreren weiteren Authentifizierungs-Sicherheitsprofilen von dem Diensteanbieter zu empfangen.
  • Gemäß einer anderen bevorzugten Ausführungsform kann die dem Identitätsanbieter zugeordnete Vorrichtung in der Lage sein, die Assertion durch eine Angabe des Authentifizierungs-Sicherheitsprofils zu ergänzen, auf dessen Basis die Authentifizierung durchgeführt wird.
  • Stattdessen oder zusätzlich kann die dem Identitätsanbieter zugeordnete Vorrichtung in der Lage sein, eine Aufforderung zur Authentifizierung eines Benutzers zu empfangen. Die Aufforderung umfasst eine Benutzerkennung, die den Benutzer für den Identitätsanbieter identifiziert, z.B. für die Vorrichtung des Identitätsanbieters. Die dem Identitätsanbieter zugeordnete Vorrichtung kann in der Lage sein, den Benutzer auf der Basis der Benutzerkennung und eines Authentifizierungs-Sicherheitsprofils zu authentifizieren und eine Assertion, welche dem Diensteanbieter die Authentifizierung des Benutzers anzeigt, zu senden. Die Assertion wird durch eine Angabe des Authentifizierungs-Sicherheitsprofils ergänzt, auf dessen Basis die Authentifizierung des Benutzers ausgeführt wird.
  • Gemäß einer anderen bevorzugten Ausführungsform kann die dem Identitätsanbieter zugeordnete Vorrichtung in der Lage sein, eine Authentifizierungserweiterung auszuführen, die auf einer weiteren Authentifizierung auf der Basis eines weiteren Authentifizierungs-Sicherheitsprofils beruht.
  • Die Erfindung wird ferner durch ein oder mehrere Computerprogramme verkörpert. Das eine oder die mehreren Computerprogramme umfassen Abschnitte von Softwarecode, die auf Vorrichtungen zum Ausführen irgendwelcher der Schritte des Authentifizierungsverfahrens geladen werden können. Das eine oder die mehreren Computerprogramme können auf einem maschinenlesbaren Medium gespeichert werden. Das maschinenlesbare Medium kann ein nichtflüchtiger oder wiederbeschreibbarer Speicher innerhalb einer Vorrichtung oder an einem externen Ort sein. Das Computerprogramm kann auch zu einer Vorrichtung zum Beispiel über ein Kabel oder eine drahtlose Verbindung als eine Folge von Signalen übertragen werden.
  • Insbesondere wird ein Computerprogramm offenbart, das auf eine Vorrichtung geladen werden kann, die einem Diensteanbieter zugeordnet ist. Das Computerprogramm umfasst Code, der dazu geeignet ist, eine Anforderung eines Zugangs eines Benutzers zu einem Dienst des Diensteanbieters zu verarbeiten, ein oder mehrere Authentifizierungs-Sicherheitsprofile zum Spezifizieren einer Authentifizierungs-Sicherheitsanforderung für eine Authentifizierung des Benutzers bei dem Dienst auszuwählen, ein Senden einer Angabe des einen oder der mehreren ausgewählten Authentifizierungs-Sicherheitsprofile und einer Benutzerkennung, die den Benutzer identifiziert, an einen Identitätsanbieter zum Anfordern der Authentifizierung des Benutzers durch den Identitätsanbieter auszulösen und eine Assertion zu verarbeiten, welche die Authentifizierung des Benutzers durch den Identitätsanbieter anzeigt.
  • Stattdessen kann das Computerprogramm auch in einer Form vorliegen, bei welcher die Softwareabschnitte, welche die Auswahl des einen oder der mehreren Authentifizierungs-Sicherheitsprofile und das Senden der Angabe des einen oder der mehreren Authentifizierungs-Sicherheitsprofile an den Identitätsanbieter betreffen, nicht enthalten sind oder übersprungen werden und stattdessen oder zusätzlich das Computerprogramm Code umfasst, der dazu geeignet ist, ein angegebenes Authentifizierungs-Sicherheitsprofil, auf dessen Basis die Authentifizierung des Benutzers durchgeführt wird, auf Akzeptanz zu prüfen, wobei das angegebene Authentifizierungsprofil in Verbindung mit der Assertion in das Computerprogramm eingegeben wird.
  • Ferner wird ein Computerprogramm offenbart, das auf eine Vorrichtung geladen werden kann, die einem Identitätsanbieter zugeordnet ist. Das Computerprogramm umfasst Code, der dazu geeignet ist, eine Aufforderung zu einer Authentifizierung eines Benutzers zu verarbeiten, wobei die Aufforderung eine Benutzerkennung, die den Benutzer für den Identitätsanbieter identifiziert, und eine Angabe für eines oder mehrere Authentifizierungs-Sicherheitsprofile, die eine Authentifizierungs-Sicherheitsanforderung des Diensteanbieters für die Authentifizierung des Benutzers bei einem Dienst des Diensteanbieters spezifizieren, umfasst, eine Authentifizierung des Benutzers auf der Basis der Benutzerkennung und eines des einen oder der mehreren Authentifizierungs-Sicherheitsprofile, die von dem Diensteanbieter empfangen wurden, durchzuführen und ein Senden einer Assertion, welche dem Diensteanbieter die Authentifizierung des Benutzers anzeigt, auszulösen.
  • Weitere Wege zum Implementieren des Verfahrens gemäß der Erfindung durch Computerprogramme sind möglich. Insbesondere können die Computerprogramme beliebige Ausführungsformen des beschriebenen Verfahrens implementieren.
  • Im Folgenden werden unter Bezugnahme auf die Figuren detaillierte Ausführungsformen der vorliegenden Erfindung beschrieben.
  • Kurzbeschreibung der Zeichnungen
  • 1a zeigt ein Beispiel für ein Authentifizierungs-Sicherheitsprofil mit Attributen;
  • 1b zeigt ein Beispiel für Authentifizierungs-Sicherheitsprofile und ihr Ordnen hinsichtlich der Stärke der Authentifizierungs-Sicherheit;
  • 2 zeigt Beispiele für Abbildungen zwischen numerischen Werten von Attributen und der Stärke der Authentifizierungs-Sicherheit;
  • 3 zeigt einen ersten beispielhaften Nachrichtenfluss für eine Authentifizierung;
  • 4 zeigt einen zweiten beispielhaften Nachrichtenfluss für eine Authentifizierung;
  • 5 zeigt einen dritten beispielhaften Nachrichtenfluss für eine Authentifizierung;
  • 6 zeigt einen vierten beispielhaften Nachrichtenfluss für eine Authentifizierung;
  • 7 zeigt einen fünften beispielhaften Nachrichtenfluss für eine Authentifizierung;
  • 8 zeigt einen sechsten beispielhaften Nachrichtenfluss für eine Authentifizierung;
  • 9 zeigt einen siebenten beispielhaften Nachrichtenfluss für eine Authentifizierung;
  • 10 zeigt einen ersten beispielhaften Nachrichtenfluss für eine Authentifizierungserweiterung;
  • 11 zeigt einen zweiten beispielhaften Nachrichtenfluss für eine Authentifizierungserweiterung;
  • 12 zeigt ein Beispiel für eine Vorrichtung zum Implementieren des Verfahrens;
  • 13 zeigt ein erstes Beispiel für Vorrichtungen und Verbindungen zwischen den Vorrichtungen zum Ausführen des Verfahrens;
  • 14 zeigt ein zweites Beispiel für Vorrichtungen und Verbindungen zwischen den Vorrichtungen zum Ausführen des Verfahrens;
  • 15 zeigt ein drittes Beispiel für Vorrichtungen und Verbindungen zwischen den Vorrichtungen zum Ausführen des Verfahrens.
  • Ausführliche Beschreibung der Erfindung
  • Das Authentifizierungsverfahren kann aus den folgenden drei Elementen bestehen: Erstens, einer Datenstruktur zum Beschreiben eines oder mehrerer Authentifizierungs-Sicherheitsprofile (ASProfs) und möglicher Relationen zwischen ASProfs als eine strukturierte, erweiterbare und maschinenlesbare Menge. Zum Beschreiben der Datenstruktur kann ein gerichteter Graph verwendet werden, um die Relation zwischen verschiedenen ASProfs auszudrücken, z.B. "ist stärker als oder gleich stark wie" (≥). In diesem Graph ist jeder Knoten ein ASProf, und jede gerichtete Kante drückt eine Relation zwischen zwei ASProfs aus. Zweitens, einem Verfahren zum Vereinbaren eines ASProf, das zur Authentifizierung eines Benutzers bei einem Dienst eines Diensteanbieters zu verwenden ist. Der Diensteanbieter kann ein oder mehrere geforderte ASProfs im Sinne einer "Wunschliste" an einen Identitätsanbieter senden, welcher seinerseits entscheidet, ob er dem entsprechen kann oder nicht, und alternative Vorschläge für ein oder mehrere zu verwendende ASProfs machen kann. Durch Verwendung von Referenzen und Aktualisierungen anstelle eines Hin- und Hersendens der vollständigen ASProfs können die ausgetauschten Daten verringert werden. Es kann mit einem weiteren Identitätsanbieter zwecks Authentifizierung Kontakt aufgenommen werden, falls der erste Identitätsanbieter die Anforderungen des Diensteanbieters nicht erfüllen kann. Drittens, einem Verfahren zum Erweitern eines ASProf während einer Sitzung; das Erweitern eines ASProf während einer Sitzung schließt ein erneutes Aushandeln des ASProf ein und kann auch eine neue Validierung von User Credentials erfordern. Falls der Identitätsanbieter dem erweiterten ASProf nicht entsprechen kann, kann der Diensteanbieter mit einem alternativen Identitätsanbieter hinsichtlich der Erweiterung Kontakt aufnehmen.
  • Der Gewissheitsgrad, dass ein Benutzer, welcher die Kennung X zu haben behauptet, tatsächlich der zu dieser Kennung gehörende Benutzer ist, ist auf einer kontinuierlichen Skala ersichtlich und hängt von einer Anzahl von Faktoren ab, zu denen unter anderem gehören:
    • – ein oder mehrere Typen von User Credentials, die zur Authentifizierung überprüft werden; zum Beispiel kann ein Passwort als weniger sicher betrachtet werden als eine Company ID (Firmenkennung) in Kombination mit einem PIN-Code;
    • – Sicherheitsmerkmale von Transport-, Vermittlungs- und Sicherungsschicht, die verwendet werden, wenn Authentifizierungsinformationen (z.B. Passwörter) zwischen Client und Server übermittelt werden, z.B. TLS, IPsec;
    • – der Zeitpunkt der letzten Authentifizierung; z.B. ist eine PIN, welche vor zehn Sekunden eingegeben worden ist, normalerweise sicherer als eine PIN, welche vor drei Tagen eingegeben worden ist, da ein Angreifer in der Zwischenzeit einen unberechtigten Zugang zu der Client-Vorrichtung erlangt haben könnte;
    • – Länge und Komplexität der User Credentials, z.B. Länge von Passwort oder PIN, ein Passwort, das nur Buchstaben enthält, gegenüber einem Passwort, das mindestens zwei Buchstaben und mindestens zwei Sonderzeichen enthält, Länge eines geheimen Schlüssels usw.;
    • – Richtlinien (Policies) in Bezug auf die Handhabung geheimer User Credentials, z.B. wie oft muss ein Passwort geändert werden, nach wie vielen Änderungen kann ein altes Passwort erneut verwendet werden, wie schützt der Identitätsanbieter die Vertraulichkeit und Unversehrtheit von geheimen User Credential Daten;
    • – Richtlinien in Bezug auf die Handhabung von Schlüsseln, wenn eine Öffentliche-Schlüssel-Infrastruktur (Public Key Infrastructure, PKI) verwendet wird, z.B. wie wird ein Zertifikatwiderruf (Certificate Revocation) gehandhabt, welchen Stammzertifikaten wird vertraut, usw.;
    • – ergriffene Maßnahmen, um Betrug zu erkennen, sowie die Prozeduren zum Widerruf (Sperrung) von Credentials und die für einen Widerruf benötigte Zeit im Falle einer Betrugserkennung;
    • – Haftung/Garantien, die dem Diensteanbieter vom Identitätsanbieter für den Fall eines Betrugs gegeben werden;
    • – Richtlinien in Bezug auf die Überprüfung der "realen" Identität des Benutzers bei der Registrierung bei dem Identitätsanbieter, z.B. kann das Eingeben eines Namens und von persönlichen Daten auf einer Webseite als weniger sicher angesehen werden als die Überprüfung eines Passes.
  • Im vorliegenden Dokument wird die Vereinigung dieser und anderer Attribute, welche den Gewissheitsgrad einer Benutzerauthentifizierung beeinflussen, als ein "Authentifizierungs-Sicherheitsprofil" ("ASProf") bezeichnet.
  • Das ASProf ist als eine Menge von Attributen beschrieben, z.B. durch diejenigen Attribute, die oben angegeben wurden, mit oder ohne Attributwerte. Zum Beispiel kann ein leeres oder Standard-ASProf Attribute haben, ohne Attributwerte zu haben, die den Attributen zugewiesen sind. Das ASProf kann man sich so vorstellen, dass es Richtlinien umfasst, die Prozesse beschreiben, mittels welcher Authentifizierungs-Credentials gehandhabt, erneuert, widerrufen werden sollen usw. Die Beschreibung eines ASProf ist vorzugsweise veränderbar, erweiterbar und maschinenlesbar. Vorzugsweise wird die extensible Markup Language (XML) als eine zugrunde liegende Metasprache verwendet. Erweiterbarkeit ist wichtig, weil ein ASProf normalerweise keine abgeschlossene Menge von Daten ist, sondern möglicherweise an neu entstehende Authentifizierungstechniken wie Biometrik und an neue Sicherheitstechniken, z.B. kryptographische Verfahren, angepasst werden muss. Erweiterbarkeit stellt sicher, dass zukünftige Attribute in das ASProf eingefügt werden können, und schließt auch Änderbarkeit ein, als eine Anforderung für das Ersetzen von Attributen eines gegebenen ASProf. Es können Relationen zwischen verschiedenen Attributen existieren.
  • 1a zeigt ein Beispiel eines ASProf A01 mit verschiedenen Attributen wie PIN B01, Chipkarte B02, Biometrik B03, Transportsicherheit B04 und Richtlinien (Policy) B05. Das ASProf kann durch weitere Attribute erweitert werden, z.B. um zukünftige Technologien B06 für die Authentifizierung zu erfassen.
  • Den Attributen eines ASProf können Attributwerte zugewiesen sein, z.B. kann die Menge der Attribute numerisch sein, d.h. "Schlüssellänge" = "128, "minimale Passwortlänge" = "10", oder deskriptiv, z.B. "Transportsicherheit" = "Tunnelung über TLS" oder "Transportsicherheit" = "WTLS", wobei TLS Transport Layer Security (Transportschicht-Sicherheit) und WTLS Wireless TLS (drahtlose TLS) bedeutet. Es wird auf 1a Bezug genommen; Attributwerte können wie folgt zugewiesen werden:
    Attribut Attributwert
    PIN 10 Zeichen
    Chipkarte keine
    Biometrik (z.B. Fingerabdruck) Hohes Auflösungsvermögen (200 kByte)
    Transportsicherheit WTLS
    Richtlinien keine
  • Ein weiteres Beispiel eines ASProf mit in XML codierten Attributen ist unten in Tabelle A dargestellt, mit Anmerkungen, die im nachfolgenden Text angegeben werden. In dem untenstehenden Beispiel existieren Relationen zwischen einigen der Attribute.
  • Figure 00330001
  • Figure 00340001
  • Figure 00350001
    Tabelle A: Beispiel für ein in XML codiertes ASProf.
  • Anmerkungen zu Tabelle A:
    • AA1: Für die Benutzerauthentifizierung wird ein Passwort mit mindestens 5 und höchstens 10 Zeichen verwendet. Die maximale Sitzungsdauer, bis eine erneute Authentifizierung erforderlich ist, beträgt 8 Stunden. Das Passwort ist Groß/Kleinschreibungsempfindlich, braucht keine Sonderzeichen zu enthalten, muss jedoch mindestens ein numerisches Zeichen enthalten.
    • AA2: Es wird TLS verwendet, um die Transportschicht sicher zu machen, zulässige Nachrichtenauthentifizierungs-Algorithmen sind Message Digest Algorithm No. 5 (MD5) und Security Hash Algorithm (SHA), zulässige Verschlüsselungsalgorithmen sind Data Encryption Standard (DES) und Triele-DES. SSL ist ebenfalls als Transportschicht-Sicherheitsprotokoll zulässig, anstelle von TLS.
    • AA3: Das Passwort muss mindestens alle drei Monate geändert werden; ein altes Passwort darf erst wiederverwendet werden, nachdem mindestens 10 andere Passwörter verwendet worden sind. Die detaillierten Vertraulichkeitsrichtlinien für den Umgang mit Benutzerdaten sind unter der angegebenen URL zu finden.
    • AA4: Verisign, RSA und Thawte sind als Root-Zertifizierungsstellen vertrauenswürdig.
    • AA5: Der Identitätsanbieter übernimmt keine Haftung ($0.00) für Betrug oder Datendiebstahl.
    • AA6: Bei der Registrierung wird die Benutzerkennung unter Verwendung einer Bestätigungs-E-Mail, die an die E-Mail-Adresse des Benutzers gesendet wird, bestätigt. Die Registrierung erlischt, wenn das Konto 6 Monate lang nicht benutzt wird. Eine Regelmäßige Erneuerung der Registrierung ist nicht erforderlich.
    • AA7: Im Falle eines entdeckten Betruges oder Diebstahls von Credentials wird garantiert, dass ein Konto innerhalb von 30 Minuten gesperrt (widerrufen) wird.
  • Mehrere ASProfs sind vorzugsweise in Bezug auf die Stärke der Authentifizierungssicherheit durch Relationen verknüpft. Die Relationen, welche die Rangfolge oder Ordnung von ASProfs ausdrücken, können mittels eines gerichteten Graphen beschrieben werden. In diesem Graph ist jeder Knoten ein ASProf. Der Graph kann einen "Wurzelknoten" haben, welcher ein leeres ASProf sein kann, d.h. keinerlei Sicherheit. Jede gerichtete Kante gibt eine Relation zwischen zwei ASProfs an, z.B. eine Relation "≥". Die Beschreibung der Menge von ASProfs und der Relation zwischen ASProfs ist vorzugsweise veränderbar, erweiterbar und maschinenlesbar. Vorzugsweise wird XML als eine zugrunde liegende Metasprache verwendet.
  • Es sind Spezialfälle vorstellbar, z.B. der Fall, dass der Graph ein n-dimensionales Gitter wird (im Falle von n Attributen). In diesem Falle existieren unabhängige Relationen für jedes der Attribute, und der Vergleich von zwei ASProfs entspricht dem separaten Vergleich jedes der Attribute. Als ein Beispiel für einen Vergleich zwischen zwei ASProfs mit einer Relation ≥:
    WENN
    Schlüssellänge 1 ≥ Schlüssellänge 2 UND Passwortlänge 1 ≥ Passwortlänge 2
    DANN
    ASProf1 ≥ ASProf2.
  • Die allgemeinere Graph-Notation ermöglicht jedoch wesentlich komplexere Spezifikationen, z.B. eine Fingerabdruckerkennung mit Schlüssellänge 64 ist sicherer als ein Passwort mit Schlüssellänge 256. Dieser Fall des "Vergleichens von Äpfeln mit Birnen" erlangt Bedeutung, wenn in einem einzigen System völlig unterschiedliche Authentifizierungsmechanismen angewendet werden. Die Graph-Notation ist allgemeiner als andere Konzepte, bei denen die einzelnen Attribute unabhängig behandelt werden, und ermöglicht das Ausdrücken von Prioritäten zwischen ungleichartigen Authentifizierungsverfahren und -technologien.
  • Dieser Graph kann im Prinzip von jedem Diensteanbieter erzeugt werden, und verschiedene Diensteanbieter können unterschiedliche Graphen verwenden. Ein Diensteanbieter kann mehrere Graphen haben, z.B. für verschiedene Benutzer oder Identitätsanbieter oder Dienste. Dies widerspiegelt die Anforderung, dass jeder Diensteanbieter vorzugsweise in der Lage ist, seine eigenen Präferenzen und Prioritäten im Hinblick auf Merkmale der Authentifizierungssicherheit zu definieren. Ein erster Diensteanbieter kann einen Iris-Scan für sicherer als ein Schlüsselwort ansehen. Ein zweiter Diensteanbieter kann das Schlüsselwort für sicherer ansehen. Dies schließt natürlich nicht die Wiederverwendung von "Standard"-Graphen aus, wenn der Diensteanbieter dies wünscht.
  • In 1b ist ein Beispiel für einen ASProf-Graphen dargestellt. Der Graph umfasst ASProfs A1, A2, A3, A4, A5, A6, A7,. A8, A9, die als Punkte dargestellt sind und durch Pfeile verbunden sind, um eine Relation ≥ zwischen zwei ASProfs auszudrücken. Die in der graphischen Darstellung von 1b verwendete Pfeilnotation bedeutet, dass ein Pfeil, der zwei ASProfs verbindet, mit seiner Pfeilspitze auf dasjenige der zwei ASProfs zeigt, das, verglichen mit dem anderen ASProf von den zwei ASProfs, ≥ ist, d.h. ASProf1 → ASProf2 bedeutet ASProf2 ≥ ASProf1. In dem Graph sind Pfeile 12, 13, 16, 24, 35, 47, 58, 68, 79, 89 zum Ausdrücken der ≥ Relationen zwischen den ASProfs zu finden.
  • Es sind Attribute und Attributwerte für Chipkarten, PINs und Biometrik dargestellt, welche zu ASProfs gehören. Insbesondere umfasst das ASProf A4 ein 56-Bit-Chipkarten-Attribut B4, das ASProf A7 umfasst ein 128-Bit-Chipkarten-Attribut B7, das ASProf A6 umfasst ein 4-Ziffern-PIN-Attribut B6, das ASProf A8 umfasst ein 10-Ziffern-PIN-Attribut B8 und das ASProf A9 umfasst ein Iris-Erkennungs-Attribut B9. Weitere Attribute oder Kombinationen von Attributen können zu den ASProfs in 1 gehören. Außerdem kann ein Wurzelknoten ASProf A1, der "keinerlei Sicherheit" angibt, definiert sein und zu ASProfs in Beziehung stehen, z.B. zu den ASProfs A2, A3, A6 über Relationen 12, 13 und 16 in 1b. Weitere ASProfs oder Relationen können in den Graphen eingefügt werden, existierende ASProfs oder Relationen können geändert oder gelöscht werden.
  • Die Kenntnis einer PIN mit 10 Ziffern ist definiert als ≥ als die Kenntnis einer PIN mit 4 Ziffern. Diese Relation ≥ ist durch einen Pfeil 68 dargestellt, der an dem ASProf A6 beginnt, das ein 4-Ziffern-PIN-Attribut B6 umfasst, und auf das ASProf A8 zeigt, das ein 10-Ziffern-PIN-Attribut B8 umfasst. Der Besitz einer Chipkarte mit einem 128 Bit langen geheimen Schlüssel ist definiert als ≥ als der Besitz einer Chipkarte mit einem 56 Bit langen geheimen Schlüssel. Dementsprechend wird die Relation ≥ zwischen dem ASProf B7 und dem ASProf B4 durch einen Pfeil 47 ausgedrückt, der von der 56-Bit-Chipkarte zu der 128-Bit-Chipkarte zeigt. Ferner kann ein Iris-Erkennungsverfahren definiert sein als ≥ als ein 10-Ziffern-Passwort sowie als als ein 128 Bit langer geheimer Schlüssel auf einer Chipkarte, wobei Pfeile 89 bzw. 79 die jeweilige Relation ≥ ausdrücken. Möglicherweise macht es jedoch nicht viel Sinn, zu versuchen zu entscheiden, ob ein 10-Ziffern-Passwort ≥ als 128 Bit langer geheimer Schlüssel auf einer Chipkarte ist. Falls eine Relation ≥ zwischen zwei ASProfs nicht realisierbar oder nicht gewünscht ist, fehlt in dem Graph ein entsprechender Pfeil.
  • Ein Beispiel einer XML-Darstellung des in 1b dargestellten Graphen ist unten angegeben. Es gibt zwei Datenstrukturen, welche gewöhnlich verwendet werden, um einen gerichteten Graphen darzustellen: (a) Verwendung einer Adjazenzliste (Nachbarschaftsliste), welche eine Liste von Paaren ist, wobei jedes Paar eine gerichtete Kante (manchmal auch als ein Pfeil oder eine Relation bezeichnet) repräsentiert, wobei das erste Element des Paares das Ursprungs-ASProf angibt und das zweite Element das Ziel-ASProf der jeweiligen gerichteten Kante angibt. (b) Verwendung einer Inzidenzmatrix, welche für jeden Ursprungsknoten eine Liste von Zielknoten enthält, zu welchen in dem Graph Kanten existieren. In dem in der untenstehenden Tabelle B angegebenen Beispiel wird eine Inzidenzmatrix-Darstellung verwendet. Es sind auch andere Darstellungen möglich.
  • Figure 00400001
  • Figure 00410001
  • Figure 00420001
    Tabelle B: Beispiel für ASProfs mit Relationen gemäß Fig. 1b, in XML codiert.
  • Anmerkungen zu Tabelle B:
    • BB1: A1 ist der Wurzelknoten des Graphen und steht für ein leeres ASProf, d.h. überhaupt keine Sicherheitsmerkmale.
    • BB2: Es gibt gerichtete Kanten in dem Graphen von dem Wurzelknoten A1 zu den Knoten A2, A3 und A6. Ein "Nachfolger" eines Knotens ist definiert als "stärker als oder gleich stark wie" der Ursprungsknoten.
    • BB3: Gemäß 1b gehört das Attribut B4 "Chipkarte" mit dem Attributwert "56 Bit" zu ASProf A4.
    • BB4: Gemäß 1b gehört das Attribut B6 "PIN" mit dem Attributwert "4 Ziffern" zu ASProf A6.
    • BB5: Gemäß 1b gehört das Attribut B7 "Chipkarte" mit dem Attributwert "128 Bit" zu ASProf A7.
    • BB6: Gemäß 1b gehört das Attribut B8 "PIN" mit dem Attributwert "10 Ziffern" zu ASProf A8.
    • BB7: Gemäß 1b gehört das Attribut B9 "Biometrik" mit dem Attributwert "Iriserkennung" zu ASProf A9.
  • Außerdem können die Attribute eines ASProf eine hierarchische Struktur haben. Zum Beispiel könnte ein Attribut "Schlüssellänge" unterschiedliche Interpretationen haben, in Abhängigkeit davon, ob das Attribut der nächsthöheren Ebene "Tunnelung über TLS" oder "WTLS" spezifiziert. Daher können die numerischen Werte des Attributes "Schlüssellänge" nicht immer direkt miteinander verglichen werden, ohne dass zuvor das Attribut der nächsthöheren Ebene verglichen wurde.
  • Im Falle von numerischen Attributwerten muss keine monotone Relation zwischen dem Attributwert und der Stärke der Authentifizierungssicherheit bestehen, in dem Sinne, dass z.B. eine größere Schlüssellänge immer eine größere Stärke der Authentifizierungssicherheit nach sich zieht. 2 zeigt ein Beispiel für eine nichtmonotone Relation: In dem Beispiel wird eine Passwortlänge von rund 9 als optimal empfunden, was die Stärke der Authentifizierungssicherheit anbelangt. Kürzere Passwörter werden als weniger sicher betrachtet, da sie leichter gebrochen werden können, z.B. mittels einer Brute-Force-Attacke im Falle von sehr kurzen Längen und mittels einer Lexikon-Attacke für längere Passwörter. Passwörter, die wesentlich länger als 9 sind, werden jedoch ebenfalls als weniger sicher betrachtet, da es wahrscheinlich ist, dass sie von dem Benutzer niedergeschrieben werden, da sie schwer zu merken sind. Der Zusammenhang zwischen dem Attributwert "Passwortlänge" und der entsprechenden Stärke der Authentifizierungssicherheit ist im oberen Teil von 2 dargestellt. Der untere Teil zeigt, wie diese Abbildung mittels eines gerichteten Graphen dargestellt werden kann, obwohl auch andere Darstellungen denkbar sind. Die Relation zwischen einem ersten ASProf mit Attribut Passwortlänge und einem zweiten ASProf mit Attribut Passwortlänge wird entsprechend durch Pfeile ausgedrückt, wobei ein Pfeil nun eine Relation "stärker" ausdrückt, d.h. dass ein erstes ASProf stärker (">") als ein zweites ASProf ist, wird durch einen Pfeil angegeben, der an dem zweiten ASProf beginnt und mit seiner Pfeilspitze an dem ersten ASProf endet. Dass das erste ASProf und das zweite ASProf von gleicher Stärke ("=") sind, wird dadurch angegeben, dass ein zusätzlicher Pfeil, der an dem ersten ASProf beginnt, mit seiner Pfeilspitze an dem zweiten ASProf endet. Zum Beispiel wird eine Relation die aussagt, dass die Stärke von zwei Passwortlängen gleich ist, durch zwei Pfeile ausgedrückt, wobei ein Pfeil von der ersten Passwortlänge zu der zweiten Passwortlänge zeigt und ein zweiter Pfeil von der zweiten Passwortlänge zu der ersten Passwortlänge zeigt. In diesem Beispiel werden Passwörter, die 11-20 Zeichen haben, als die gleiche Stärke der Authentifizierungssicherheit wie Passwörter mit 3-6 Zeichen aufweisend definiert.
  • Tatsächlich kann es vollkommen dem Diensteanbieter überlassen werden, über seine eigenen Präferenzen und Prioritäten zu entscheiden; z.B. kann sich ein erster Diensteanbieter für eine monotone Abbildung entscheiden, ein weiterer Diensteanbieter kann sich für eine Abbildung gemäß 2 entscheiden, und ein dritter Diensteanbieter kann einen Standard-Graphen von einem Identitätsanbieter akzeptieren, ohne sich um die Einzelheiten der Abbildung zu kümmern.
  • Das Beispiel von 2 veranschaulicht, wie eine nichtmonotone Relation in einem gerichteten Graphen dargestellt werden kann. Es veranschaulicht ferner, wie Bereiche von Attributwerten, z.B. "7-10 Zeichen", in der Darstellung des Graphen zu einem einzigen Knoten zusammengefasst werden können, d.h. es besteht keine Notwendigkeit, dass jeder zulässige numerische Wert einen separaten Knoten in dem Graphen bildet.
  • Im Folgenden wird die Authentifizierung eines Benutzers bei einem Dienst eines Diensteanbieters SP durch einen oder mehrere Identitätsanbieter beschrieben:
    Gemäß 3 nimmt ein Client Kontakt mit einem von einem Diensteanbieter SP angebotenen Dienst auf, welchen der Benutzer in Anspruch nehmen möchte, indem er mittels Nachricht 1a eine Dienstanforderung sendet. Der Dienst erfordert eine Benutzerauthentifizierung, und der Diensteanbieter SP sendet mittels Nachricht 1b eine Aufforderung zur Benutzerauthentifizierung an den Client. Der Client liefert mittels Nachricht 1c eine Benutzerkennung an den Diensteanbieter SP, welcher die Benutzerkennung überprüfen kann. Wenn der Identitätsanbieter IdP1 für die Authentifizierung des Clients dem Diensteanbieter SP unbekannt ist, sendet der Client mittels Nachricht 1c einen Verweis auf einen Identitätsanbieter IdP1, z.B. einen Uniform Resource Identifier (URI), an den SP. Optional wird der Verweis auf einen Identitätsanbieter IdP1 standardmäßig von dem Client an den Diensteanbieter SP gesendet.
  • Der Diensteanbieter SP fordert eine Authentifizierung des Benutzers an, indem er mittels Nachricht 2 ein gewünschtes ASProf, das die Authentifizierungs-Sicherheitsanforderung des Dienstes spezifiziert, und die Benutzerkennung an den Identitätsanbieter IdP1 sendet. Normalerweise richten der Diensteanbieter SP und der Identitätsanbieter IdP1 eine sichere Sitzung ein (z.B. unter Verwendung von TLS), welche Vertraulichkeit, Integrität und Authentizität der von ihnen ausgetauschten Informationen gewährleistet, sowie eine einseitige oder gegenseitige Authentifizierung zwischen dem Diensteanbieter SP und dem Identitätsanbieter IdP1. Prozesse und Nachrichten, welche für eine beliebige Art von Verschlüsselung zwischen Entitäten beliebiger Art, die an dem vorgeschlagenen Authentifizierungsverfahren beteiligt sind, notwendig sind, sind weder in 3 noch in den folgenden Figuren dargestellt.
  • Der Identitätsanbieter IdP1 prüft in Prozess 3a, ob er die Anforderungen, die in dem von dem SP empfangenen ASProf dargelegt sind, erfüllen kann oder nicht. Falls die Anforderungen erfüllt werden können, kann der Identitätsanbieter IdP1 in Prozess 3a ferner prüfen, ob eine Überprüfung von User Credentials erforderlich ist oder nicht. Falls eine Überprüfung von Credentials erforderlich ist, kann eine Anforderung 3b von User Credentials zu dem Client gesendet werden, und der Client kann mittels Nachricht 3c auf diese Anforderung 3b antworten, indem er die angeforderten User Credentials sendet. Für die Anforderung 3b und die entsprechende Antwort 3c ist sowohl In-Band- als auch Out-of-Band-Kommunikation möglich. Auf der Basis eines positiven Ergebnisses der Prüfung der Anforderungen des ASProf und der optionalen Überprüfung der Credentials sendet der Identitätsanbieter IdP1 mittels Nachricht 3d eine Assertion der Benutzerauthentifizierung an den SP. Auf der Basis der Assertion kann der Diensteanbieter SP dem Client Zugang gewähren, damit dieser auf die angeforderte Dienstsitzung zugreifen kann.
  • Beispiel für die Überprüfung von User Credentials: Ein Benutzer hat um 9 Uhr über einen Identitätsanbieter (IdP) die Verwendung eines Benutzername-/Passwort-Mechanismus für sein Lieblings-Webportal authentifiziert. Um 11 Uhr möchte der Benutzer auf sein Profil bei einem Diensteanbieter zugreifen, der einen Dienst für einen Internet-Buchverkauf anbietet, wobei dieser Diensteanbieter auch Authentifizierungs-Assertionen von demselben IdP akzeptiert. Falls dieser Diensteanbieter in seinem ASProf fordert, dass die Passworteingabe nicht mehr als eine Stunde alt sein darf, muss der IdP den Benutzer auffordern, erneut ein Passwort einzugeben, bevor der Benutzer bei diesem Diensteanbieter authentifiziert werden kann. Falls dagegen dieser Diensteanbieter Passworteingaben akzeptiert, welche bis zu 24 Stunden alt sind, besteht keine Notwendigkeit, das Passwort erneut einzugeben.
  • Gemäß 3 und der Beschreibung von 3 wird nur ein ASProf von dem Diensteanbieter SP an den Identitätsanbieter IdP1 gesendet. Das vorgeschlagene Verfahren kann jedoch leicht an den Fall angepasst werden, dass mehrere gewünschte ASProfs von dem Diensteanbieter SP an den Identitätsanbieter IdP1 gesendet werden. In diesem Falle sendet der Diensteanbieter SP eine "Wunschliste" von ASProfs, welche der Diensteanbieter SP als ausreichend für eine Authentifizierung des Clients betrachtet. Der Identitätsanbieter IdP1 prüft die Wunschliste. Wenn eines oder mehrere der ASProfs der Wunschliste von dem Identitätsanbieter IdP1 unterstützt werden, kann der Identitätsanbieter IdP1 dasjenige von den ASProfs auswählen, welches von dem Identitätsanbieter IdP1 am besten unterstützt wird, z.B. wo keine Credential-Überprüfung notwendig ist oder die Credential-Überprüfung weniger schwierig ist, verglichen mit den weiteren unterstützten ASProfs der Wunschliste.
  • Das in Verbindung mit 3 beschriebene Verfahren verwendet einen "Rückkanal"-Nachrichtenfluss, der einen direkten Nachrichtenaustausch zwischen dem Identitätsanbieter IdP1 und dem SP beinhaltet. Stattdessen kann das Verfahren auch unter Anwendung einer "Frontkanal"-Kommunikation implementiert werden, d.h. jede beliebige Kommunikation zwischen dem Identitätsanbieter IdP1 und dem Diensteanbieter SP wird von dem Client weitergeleitet, vorzugsweise unter Anwendung geeigneter Sicherheitsvorkehrungen, so dass der Client die vor und zurück durchlaufenden Informationen nicht manipulieren kann. Eine Kombination von Rückkanal und Frontkanal für verschiedene Nachrichten ist ebenfalls möglich.
  • Ein Beispiel für eine Frontkanal-Kommunikation für eine 3 entsprechende Authentifizierung ist in 4 dargestellt. Bei einer Frontkanal-Kommunikation werden das gewünschte ASProf und optional die Benutzerkennung mittels Nachricht 42a von dem Diensteanbieter SP an den Client gesendet. Der Client sendet mittels Nachricht 42b das gewünschte ASProf und die Benutzerkennung an den Identitätsanbieter IdP1. Wenn die Benutzerkennung nicht durch den Diensteanbieter SP geliefert wird, beschafft der Client die Benutzerkennung und sendet sie mittels Nachricht 42b an den Identitätsanbieter IdP1. Wie in 3 kann der Identitätsanbieter IdP1 in Prozess 3a das empfangene ASProf prüfen, und ob eine Credential-Überprüfung notwendig ist. Ist dies der Fall, kann der Identitätsanbieter IdP1 die User Credentials unter Verwendung von Nachrichten 3b, 3c überprüfen. Wie in 3 sind die Nachrichten 3b, 3c optional, und es kann In-Band- oder Out-of-Band-Kommunikation angewendet werden. Die Sicherheits-Assertion, die von dem Identitätsanbieter IdP1 gegeben wird, wird mittels der Nachrichten 43d, 43e über den Client an den Diensteanbieter SP gesendet. In diesem Falle kann die Sicherheits-Assertion als ein Authentifizierungstoken oder -ticket betrachtet werden.
  • Im Falle eines mobilen Clients hat eine Rückkanal-Implementierung den Vorteil, dass eine Kommunikation zwischen dem Diensteanbieter SP und dem Identitätsanbieter IdP1 über die Luftschnittstelle des Clients vermieden wird. Bei Frontkanal-Kommunikation wird für den alleinigen Zweck der Übermittlung von Informationen zurück und vor zwischen dem Diensteanbieter SP und dem Identitätsanbieter IdP1 zusätzliche Bandbreite verwendet und zusätzliche Latenz verursacht.
  • Eine Frontkanal-Implementierung ist für Festnetze wie das Internet üblich und kann gegenüber einer Rückkanal-Implementierung bevorzugt werden, um den Implementierungsaufwand zu verringern. Sie hat außerdem den Vorteil, dass eine Sitzungsumleitung stattfindet, d.h. die Anforderung an den Diensteanbieter SP in 1c von 4 wird durch eine Antwort von dem Diensteanbieter SP in Nachricht 42a beantwortet und nicht, wie im Falle des Rückkanals, durch eine Antwort von einem Identitätsanbieter IdP1. Dies kann bewirken, dass die für die Authentifizierung benötigte Gesamtzeit kürzer ist als bei der Rückkanal-Kommunikation.
  • Es kann auch eine Hybrid-Implementierung möglich sein, zum Beispiel unter Verwendung eines Proxy-Servers, um einen Frontkanal für die Kommunikation zwischen dem Diensteanbieter SP und dem Identitätsanbieter IdP1 zu emulieren und gleichzeitig Verkehr über den Client zu vermeiden. Eine Hybrid-Implementierung kann daher für einen mobilen Client sehr nützlich sein.
  • Für den Fall, dass der Identitätsanbieter IdP1, wie in Verbindung mit 3 beschrieben, das gewünschte eine oder die gewünschten mehreren ASProfs, die von dem Diensteanbieter SP an den Identitätsanbieter IdP1 gesendet werden, nicht unterstützt, kann der Identitätsanbieter IdP1 dem Diensteanbieter SP einen Gegenvorschlag für das eine oder die mehreren gewünschten ASProfs liefern. Gemäß 5 sendet der Diensteanbieter SP mittels Nachricht 2 eine Aufforderung zur Authentifizierung, welche das gewünschte ASProf und die Benutzerkennung umfasst, an den Identitätsanbieter IdP1. Der Identitätsanbieter IdP1 prüft das empfangene gewünschte ASProf und stellt fest, dass das gewünschte ASProf nicht unterstützt wird. Es werden ein oder mehrere alternative ASProfs bestimmt und mittels Nachricht 4 als vorgeschlagene alternative ASProfs von dem Identitätsanbieter IdP1 an den SP gesendet. Der Diensteanbieter SP prüft in Prozess 5a, ob wenigstens eines des einen oder der mehreren vorgeschlagenen alternativen ASProfs akzeptabel ist. Falls keines der empfangenen vorgeschlagenen alternativen ASProfs akzeptabel ist, kann der Diensteanbieter SP ein oder mehrere weitere gewünschte ASProfs an den Identitätsanbieter IdP1 senden, oder er kann mit einem weiteren Identitätsanbieter IdP1 zwecks Authentifizierung Kontakt aufnehmen, oder er kann die Authentifizierung beenden. Falls wenigstens eines von dem einen oder den mehreren vorgeschlagenen alternativen ASProfs akzeptabel ist, sendet der Diensteanbieter SP mittels Nachricht 5b eine Genehmigung des wenigstens einen vorgeschlagenen alternativen ASProf an den Identitätsanbieter IdP1. Falls mehrere vorgeschlagene alternative ASProfs akzeptabel sind, kann der Diensteanbieter SP eines der mehreren ASProfs auswählen, bevor er die Genehmigung für das ausgewählte ASProf sendet; z.B. kann der Diensteanbieter SP das empfangene eine oder die empfangenen mehreren vorgeschlagenen alternativen ASProfs prüfen und die Prüfung abbrechen, nachdem ein erstes ASProf für akzeptabel befunden wurde. Dieses ASProf wird von dem Diensteanbieter SP genehmigt, und eine Anzeige der Genehmigung dieses ASProf wird an den Identitätsanbieter IdP1 gesendet. Für das genehmigte ASProf fährt der Identitätsanbieter IdP1 mit den Prozessen und Nachrichten 3a-3d fort, die in Verbindung mit 3 beschrieben wurden.
  • Wie oben in Verbindung mit 3-5 beschrieben wurde, wünscht der Diensteanbieter SP, dass ein oder mehrere ASProfs von dem Identitätsanbieter IdP1 verwendet werden, in dem Sinne, dass das eine oder die mehreren gewünschten ASProfs an den Identitätsanbieter IdP1 gesendet werden. Der Diensteanbieter SP muss jedoch nicht unbedingt das eine oder die mehreren gewünschten ASProfs in der Aufforderung zur Authentifizierung an den Identitätsanbieter IdP1 senden. Stattdessen kann der Diensteanbieter SP eine Liste von unterstützten ASProfs von dem Identitätsanbieter IdP1 anfordern. Dies ist in 6 dargestellt. Der Diensteanbieter SP sendet mittels Nachricht 62a die Benutzerkennung an den Identitätsanbieter IdP1 und fordert eine Authentifizierung an. Der Identitätsanbieter IdP1 antwortet mittels Nachricht 62b mit einer Liste von ASProfs, die von dem Identitätsanbieter IdP1 unterstützt werden. Die Liste wird in Prozess 62c von dem Diensteanbieter SP geprüft, und es wird ein akzeptables ASProf aus der Liste ausgewählt. Das ausgewählte ASProf (als ein Beispiel für eine Angabe) oder eine Angabe des ausgewählten ASProf wird mittels Nachricht 62d an den Identitätsanbieter IdP1 gesendet. Das Senden des ausgewählten ASProf (als ein Beispiel für eine Angabe) oder der Angabe kann durch die Benutzerkennung ergänzt werden, um das ausgewählte ASProf mit der Aufforderung zur Authentifizierung zu korrelieren, die mittels Nachricht 62a gesendet wurde. Der Identitätsanbieter IdP1 kann in Prozess 63a prüfen, ob eine Credential-Überprüfung für das ausgewählte ASProf notwendig ist, und fährt mit den Prozessen und Nachrichten gemäß 3b-3d fort, wie in Verbindung mit 3 beschrieben.
  • Das Senden von ASProfs kann durchgeführt werden, indem einzelne ASProfs mit oder ohne eine Relation, welche die Stärke des Sicherheitsniveaus aufzeigt, gesendet werden. Es können einzelne ASProfs oder ASProfs und Informationen über die Relation zwischen den ASProfs gesendet werden. Zum Beispiel kann, im Hinblick auf die Graph-Notation, die in Verbindung mit 1 und 2 beschrieben wurde, der vollständige Graph gesendet werden, oder Teile des Graphen, wie ASProfs und Pfeile. Der Absender der ASProfs, z.B. der Diensteanbieter SP, kann die ASProfs angeben, deren Verwendung durch den Empfänger, d.h. den Identitätsanbieter IdP1, gewünscht ist. Insbesondere in dem Falle, wenn der Empfänger keines der gewünschten ASProfs unterstützt, kann der Empfänger durch den Graphen navigieren, beginnend bei den gewünschten ASProfs, um festzustellen, ob er ein ASProf unterstützen kann, welches als gleich stark wie oder stärker als ein gewünschtes ASProf erkannt wird, falls Informationen über die Relation zwischen ASProfs beim Empfänger verfügbar sind. Beim Navigieren durch den Graphen oder Teile des Graphen, die dem Empfänger bekannt sind, kann der Empfänger wenigstens ein ASProf auswählen, das gleich stark oder stärker ist, um die Anforderungen bezüglich der Stärke des ASProf zu erfüllen, die vom Absender gewünscht werden.
  • Ein entsprechendes Beispiel für eine Navigation ist in 7 dargestellt, wobei der Diensteanbieter mittels Nachricht 72a einen Teil des ASProf Graphen oder den vollständigen Graphen, eine Angabe für das gewünschte ASProf und die Benutzerkennung an den IdP1 zur Authentifizierung sendet. Anstatt den vollständigen Graphen zu senden, kann der Diensteanbieter SP nur denjenigen Teil des Graphen senden, der ASProfs umfasst, die gleich stark wie oder stärker als das gewünschte ASProf sind, z.B. um den Übertragungsaufwand zu verringern oder um dem Identitätsanbieter keine Informationen zu liefern, die für diese Authentifizierung nicht verwendbar sind. Der Identitätsanbieter IdP1 prüft im Prozess 73a, ob das gewünschte ASProf unterstützt wird. Falls es nicht unterstützt wird, prüft der Identitätsanbieter IdP1 in Prozess 73a, ob ein stärkeres ASProf (wie in 7 dargestellt) oder ein ASProf von gleicher Stärke unterstützt wird, indem er durch den Graphen navigiert, den vom SP empfangen hat. Falls wenigstens ein ASProf, das stärker als oder von gleicher Stärke wie das nicht unterstützte gewünschte ASProf und von diesem verschieden ist, von dem Identitätsanbieter IdP1 unterstützt wird, kann der Identitätsanbieter IdP1 in Prozess 73a eine Überprüfung von User Credentials vornehmen und sie, falls erforderlich, von dem Benutzer anfordern, wie in Verbindung mit 3 beschrieben wurde (Prozess und Nachrichten 3a-3c). Falls ein gleich starkes oder stärkeres ASProf verwendet wird und optional die User Credentials überprüft werden, sendet der Identitätsanbieter IdP1 mittels Nachricht 73d eine Assertion der Benutzerauthentifizierung, die vorzugsweise durch eine Angabe des verwendeten gleich starken oder stärkeren ASProf ergänzt wird, an den Identitätsanbieter IdP1. Vor der Gewährung des Zugangs zu dem Dienst für den Client kann der Diensteanbieter SP in Prozess 73e prüfen, ob das verwendete ASProf für den Diensteanbieter SP akzeptabel ist, z.B. die Authentifizierungs-Sicherheitsanforderungen des Diensteanbieters SP erfüllt.
  • Die Übertragung des Graphen oder von Teilen des Graphen, wie oben erläutert, macht das vorgeschlagene Verfahren wesentlich effizienter, was die Anzahl von Nachrichtenübertragungen hin und zurück anbelangt, wenn der Diensteanbieter SP und der Identitätsanbieter – wenigstens bis zu einem gewissen Grade – ähnliche Vorstellungen davon haben, was ein ASProf stärker als oder gleich stark wie ein anderes ASProf macht, d.h. wenn sie über gemeinsame Informationen über ASProfs und die Relationen zwischen ASProfs in Bezug auf die Stärke der Stärke der Authentifizierungssicherheit verfügen. Außerdem hat die Übertragung des Graphen den Vorteil, dass die Anzahl der hin- und hergesendeten Nachrichten zwischen Diensteanbieter SP und Identitätsanbieter auf ein Minimum begrenzt wird, was den Authentifizierungsdienst wesentlich schneller macht und dabei nach wie vor garantiert, dass die Sicherheitspräferenzen und -prioritäten des SP beachtet werden.
  • Wenn zum Beispiel ein Diensteanbieter SP eine Schlüssellänge von 128 Bit anfordert und der Identitätsanbieter nur entweder 64 Bit oder 256 Bit zur Verfügung stellen kann, dann ist es vorteilhaft, wenn der Diensteanbieter SP und der Identitätsanbieter gemeinsam der Ansicht sind, dass ein 256-Bit-Schlüssel von dem Diensteanbieter SP als stärker als ein 128-Bit-Schlüssel akzeptiert wird. Wenn diese Ansicht nicht geteilt wird, müssen zusätzliche Nachrichten ausgetauscht werden, bis der Diensteanbieter SP und der Identitätsanbieter sich auf ein zu verwendendes ASProf einigen können. Ohne die Kenntnis der Relation, dass ein 256-Bit-Schlüssel stärker als ein 128-Bit-Schlüssel ist, sendet zum Beispiel der Identitätsanbieter eine Angabe an den Diensteanbieter SP, dass 128-Bit-Schlüssel nicht unterstützt werden. Für diesen Fall kann der Diensteanbieter SP mit einem alternativen ASProf von 256 Bit antworten, welcher unterstützt wird.
  • Die geteilte Vorstellung darüber, ob ein ASProf gleich stark wie oder stärker als ein anderes ist, kann implizit oder explizit sein. Ein Beispiel für eine implizite Vereinbarung ist der obige Fall "128 Bit gegenüber 256 Bit", welcher bedeutet, dass 256 Bit allgemein als stärker als 128 Bit angesehen werden. Der Identitätsanbieter, welcher 128 Bit nicht liefern kann, verwendet stattdessen 256 Bit und teilt diese Tatsache dem Diensteanbieter SP in dem ASProf mit, unter der Annahme, dass der Diensteanbieter SP 256 Bit akzeptabel finden wird, wenn der Diensteanbieter SP 128 Bit angefordert hat. Falls jedoch der Diensteanbieter SP eine andere Definition der Stärke eines ASProf verwendet hat als der Identitätsanbieter, führt die falsche Annahme des Identitätsanbieters zu einer zusätzlichen Neuverhandlung und zusätzlichen Nachrichten oder zu einer Beendigung der Authentifizierung. Ein Beispiel, in dem eine explizite geteilte Ansicht zwischen dem Diensteanbieter SP und dem Identitätsanbieter gegenüber einer impliziten geteilten Ansicht vorzuziehen ist, ist in 2 angegeben, wo der Diensteanbieter eine nichtmonotone und nicht allgemein anerkannte Relation zwischen einem numerischen Attribut und der empfundenen Stärke der Authentifizierungssicherheit definiert.
  • 8 zeigt eine Authentifizierung, bei welcher der Diensteanbieter SP mittels Nachricht 2a eine Aufforderung zur Authentifizierung sendet, welche das gewünschte ASProf und die Benutzerkennung umfasst, jedoch ohne weitere Informationen über einen Graphen des SP zu senden. Der Identitätsanbieter IdP1 unterstützt das gewünschte ASProf nicht, und der Identitätsanbieter IdP1 wählt ein alternatives ASProf aus, wie in Prozess 83a dargestellt. Der Identitätsanbieter prüft in Prozess 83a, ob eine Credential-Überprüfung notwendig ist. Nach einer optionalen Überprüfung von User Credentials unter Verwendung der Nachrichten 3b und 3c entsprechend den in Verbindung mit 3 gegebenen Erläuterungen werden die Assertion der Benutzerauthentifizierung und eine Angabe des verwendeten alternativen ASProf mittels Nachricht 83d an den SP gesendet. Der Diensteanbieter SP prüft in Prozess 83e, ob das alternative ASProf akzeptabel ist oder nicht. Wenn das ASProf akzeptabel ist, kann die Dienstsitzung beginnen. Zum Wählen des alternativen ASProf kann der Identitätsanbieter seine eigene Notation verwenden, z.B. durch Verwenden eines eigenen Graphen oder Übernehmen einer expliziten Notation. Um jedoch zu vermeiden, dass der Diensteanbieter SP das alternative ASProf inakzeptabel findet, verwendet der Identitätsanbieter IdP1 vorzugsweise eine Notation, die von dem Diensteanbieter SP und dem Identitätsanbieter IdP1 gemeinsam genutzt wird. Ein Graph, welcher die Ordnung gemäß dem Diensteanbieter SP widerspiegelt, kann zur Verfügung gestellt werden, wenn der Diensteanbieter SP bei dem von dem Identitätsanbieter IdP1 angebotenen Authentifizierungsdienst registriert wird. Für Ad-hoc-Szenarien, in denen bei dem Identitätsanbieter IdP1 keine weiteren Informationen verfügbar sind als das gewünschte ASProf und die Benutzerkennung, kann der Identitätsanbieter IdP1 jedoch vorzugsweise seine eigene Notation verwenden, z.B. seinen eigenen Graphen, oder er kann eine oder mehrere unterstützte ASProfs, z.B. in Form eines Graphen, von dem Identitätsanbieter anfordern.
  • Durch ein Verknüpfen von ASProfs mit Relationen können Gruppen von ASProfs erzeugt werden. Zum Beispiel kann eine Anzahl von ASProfs verknüpft werden, indem jedes Paar aus dieser Anzahl von ASProfs durch eine Relation "=" verknüpft wird, so dass eine Gruppe von ASProfs mit gleicher Stärke der Authentifizierungssicherheit gebildet wird, z.B. wie in 2 durch die ASProfs mit 3-6 und 11-20 Zeichen angegeben ist, die eine Gruppe mit gleicher Starke der Authentifizierungssicherheit bilden. Der Diensteanbieter kann dem Identitätsanbieter angeben, irgendeines der zu einer gewissen Gruppe gehörenden ASProfs durch Auswählen eines der zu dieser Gruppe gehörenden ASProfs für die Authentifizierung des Benutzers zu verwenden und eine Angabe des ausgewählten ASProf an den Identitätsanbieter für die Authentifizierung des Benutzers zu senden. Wenn der Identitätsanbieter über die angegebene Gruppe informiert ist, z.B. aufgrund der Tatsache, dass Informationen über die charakteristischen Merkmale der Gruppe, d.h. die ASProfs und ihre Relationen, von dem Diensteanbieter SP an den IdP oder umgekehrt geliefert werden, kann der Identitätsanbieter auf der Basis der Angabe ein ASProf für die Authentifizierung aus der Gruppe auswählen. Um dem Identitätsanbieter die Gruppe anzugeben, kann eine Gruppenkennung verwendet werden, falls der Diensteanbieter und der Identitätsanbieter gemeinsam dieselbe Notation der Gruppe verwenden. Die einzelnen Gruppen können hierarchisch geordnet sein; z.B. kann eine erste Gruppe, die eine erste Anzahl von ASProfs umfasst, durch eine Relation mit einer zweiten Gruppe von ASProfs verknüpft sein, und der Identitätsanbieter kann zur Authentifizierung von einer Gruppe zu einer anderen Gruppe navigieren. Um zu prüfen, ob das ASProf, auf dessen Basis die Authentifizierung durchgeführt wird, den Authentifizierungs-Sicherheitsanforderungen des Diensteanbieters genügt, kann eine Angabe der Gruppe, zu der dieses Authentifizierungs-Sicherheitsprofil gehört, ausreichend sein. Das Bilden von Gruppen kann den Vorteil einer besseren Skalierbarkeit und Handhabbarkeit von Authentifizierungs-Sicherheitsprofilen mit vergleichbaren charakteristischen Eigenschaften wie vergleichbaren Credential-Typen oder vergleichbaren Erzeugungs- oder Gültigkeitszeiträumen haben.
  • Als ein alternatives Authentifizierungsverfahren kann der Diensteanbieter SP um eine Authentifizierung ersuchen, ohne irgendein ASProf zu spezifizieren. Ein entsprechendes Szenario ist in 9 dargestellt. Der Diensteanbieter SP sendet mittels Nachricht 62a eine Aufforderung zur Authentifizierung, die eine Benutzerkennung umfasst, an den Identitätsanbieter IdP1. Der Identitätsanbieter IdP1 verwendet ein ASProf seiner eigenen Wahl, wie in Prozess 93a angegeben, und führt optional eine Credential-Überprüfung gemäß dem gewählten ASProf durch, z.B. unter Verwendung von Nachrichten 3b, 3c, wie in Verbindung mit 3 erläutert wurde. Danach sendet der Identitätsanbieter IdP1 mittels Nachricht 93d eine Angabe des verwendeten ASProf oder, als eine alternative Form einer Angabe, das verwendete ASProf selbst an den Diensteanbieter SP, zusammen mit der Assertion der Authentifizierung. Der Diensteanbieter SP entscheidet dann, ob die Authentifizierung akzeptiert werden soll oder nicht, d.h. es wird in Prozess 93e geprüft, ob das verwendete ASProf akzeptabel ist oder nicht.
  • Das Verfahren zum Erweitern einer Benutzerauthentifizierung für einen Diensteanbieter SP durch einen Identitätsanbieter während einer Dienstsitzung wird in den folgenden zwei 10 und 11 beschrieben. Gemäß 10 nimmt ein Client an einer Dienstsitzung teil. Der Aufbau der Dienstsitzung mit einer ersten Authentifizierung des Benutzers bei dem Dienst des Diensteanbieters kann entsprechend der Beschreibung von 3 bis 9 erfolgen. Während der Dienstsitzung greift der Kunde auf einen Dienst zu, welcher ein höheres Sicherheitsniveau erfordert als die aufgebaute Sitzung. Ein Beispiel für ein höheres Sicherheitsniveau ist, dass ein Benutzer auf sein Online-Bankkonto mittels eines aus 5 Ziffern bestehenden PIN-Codes zugreifen kann. Falls der Benutzer jedoch zusätzlich eine Geldtransaktion von seinem Bankkonto genehmigen möchte, wird ein zusätzliches, zur einmaligen Verwendung bestimmtes Passwort, oder TAN, benötigt. Ein anderes Beispiel ist, dass ein Benutzer auf sein personalisiertes Webportal mittels eines Passwortes zugreifen kann. Einige Dienste auf dem Portal können einer Gebühr unterliegen. Wenn der Benutzer einen solchen Dienst anklickt, kann eine Authentifizierung unter Verwendung eines Chipkartenlesers, der an den PC des Benutzers angeschlossen ist, erforderlich sein.
  • Der Diensteanbieter SP erkennt die Dienstanforderung, die mittels Nachricht 102a von dem Client an den Diensteanbieter SP gesendet wird, und wählt ein ASProf aus, im Weiteren modifiziertes ASProf genannt, das den strengeren Anforderungen genügt, d.h. das modifizierte ASProf ist stärker als das ASProf, das für die erste Authentifizierung verwendet wird. Der Diensteanbieter SP sendet mittels Nachricht 102b eine Aufforderung zur Authentifizierung, welche das modifizierte ASProf und die Benutzerkennung umfasst, an einen Identitätsanbieter, der nicht notwendigerweise mit einem für die erste Authentifizierung verwendeten Identitätsanbieter identisch ist. Der Identitätsanbieter IdP1 prüft in Prozess 103a, ob er in der Lage ist, die Anforderungen des stärkeren ASProf zu erfüllen. Ist dies der Fall, prüft der Identitätsanbieter IdP1 in Prozess 103a, ob dieses stärkere ASProf eine erneute Überprüfung von User Credentials erfordert, und führt, falls erforderlich, mittels der Nachrichten 103b, 103c diese Überprüfung durch. Wie in 3 können die optionalen Nachrichten 103b, 103c mittels In- oder Out-of-Band-Kommunikation ausgetauscht werden. Danach wird fortgefahren, wie in Verbindung mit 3 beschrieben wurde, was die Assertion der Benutzerauthentifizierung betrifft, die von dem Identitätsanbieter IdP1 mittels Nachricht 103d an den Diensteanbieter SP gesendet wird. Auf der Basis der Assertion kann der Diensteanbieter SP Zugang zu dem Dienst gewähren, welcher das erweiterte ASProf erfordert, und die Dienstsitzung kann fortgesetzt werden. Anstelle des Sendens des ausgewählten ASProf (als eine Form einer Angabe) kann eine Angabe wie etwa ein URI für das ausgewählte ASProf gesendet werden, z.B. wenn das ausgewählte ASProf dem Identitätsanbieter IdP1 bekannt oder zugänglich ist. Falls das bei der ersten Authentifizierung verwendete ASProf dem Identitätsanbieter IdP1 bekannt ist, kann der Diensteanbieter SP stattdessen einen Hinweis senden, ein ASProf zu verwenden, das stärker ist als das bei der ersten Authentifizierung verwendete ASProf. In diesem Falle kann der Identitätsanbieter IdP1 die Auswahl des modifizierten ASProf vornehmen, z.B. durch Navigieren in einem Graphen. Vorzugsweise wird dieses modifizierte ASProf, das für die erweiterte Authentifizierung verwendet wird, dem Diensteanbieter SP angezeigt und von ihm für die erweiterte Authentifizierung genehmigt.
  • 11 zeigt den Fall, dass von einem ersten Identitätsanbieter IdP1 eine Authentifizierung durchgeführt und eine Dienstsitzung eingerichtet worden ist und der Client einen Dienstzugang zu einem Dienst anfordert, der ein höheres Sicherheitsniveau erfordert als die aufgebaute Sitzung. Der Diensteanbieter SP erkennt dementsprechend die mittels Nachricht 112a gesendete Dienstanforderung, die das höhere Sicherheitsniveau erfordert, und sendet mittels Nachricht 112b eine Aufforderung zur Authentifizierung, die das modifizierte ASProf und die Benutzerkennung umfasst, an den ersten IdP. Der erste Identitätsanbieter IdP1 prüft in Prozess 113a1 das empfangene modifizierte ASProf und erkennt, dass das modifizierte ASProf nicht unterstützt wird. Dementsprechend sendet der erste Identitätsanbieter IdP1 mittels Nachricht 113b eine Ablehnung des modifizierten ASProf und optional alternative ASProfs, welche von dem ersten Identitätsanbieter IdP1 unterstützt werden. Der Diensteanbieter SP kann in Prozess 113c die alternativen ASProfs prüfen und sie als inakzeptabel erachten. An den ersten Identitätsanbieter IdP1 kann eine Antwort auf die Ablehnung gesendet werden, um anzuzeigen, dass die Authentifizierung in Bezug auf den ersten Identitätsanbieter IdP1 beendet ist. An diesem Punkt kann der Diensteanbieter SP die Authentifizierungserweiterung beenden, oder er kann einen zweiten Identitätsanbieter IdP2 für die Authentifizierungserweiterung wählen. Wenn ein zweiter Identitätsanbieter IdP2 verfügbar ist, wird eine weitere Aufforderung zur Authentifizierung mittels Nachricht 112b an den zweiten Identitätsanbieter IdP2 gesendet. Die weitere Aufforderung umfasst das modifizierte ASProf und eine Benutzerkennung, die mit der für die erste Authentifizierung bei dem ersten Identitätsanbieter IdP1 verwendeten Benutzerkennung identisch ist oder auch nicht. Der zweite Identitätsanbieter IdP2 prüft in Prozess 113a2, ob das modifizierte ASProf unterstützt wird. Falls das modifizierte ASProf unterstützt wird, kann, falls erforderlich, eine Überprüfung von User Credentials durchgeführt werden, z.B. unter Verwendung von Nachrichten 113b, 113c über In- oder Out-of-Band-Kommunikation. Eine Assertion der Benutzerauthentifizierung wird mittels Nachricht 113d an den SP gesendet. Auf der Basis dieser Assertion kann der SP den Zugang zu dem Dienst gewähren, der strengere Sicherheitsanforderungen hat, und die Dienstsitzung kann fortgesetzt werden.
  • Weitere beispielhafte Erweiterungsszenarien sind: Ein Benutzer wird über ein Passwort von seinem Internetdiensteanbieter (Internet Service Provider, ISP), manchmal auch Internetzugangsanbieter genannt, authentifiziert. Zu einem bestimmten Zeitpunkt möchte der Benutzer auf einen Video-Streaming-Dienst zugreifen, für welchen eine Gebühr zu entrichten ist und welcher eine stärkere Authentifizierung erfordert, z.B. über ein Mobiltelefon (Subscriber Identity Module [Teilnehmer- Kennungsmodul]/Wireless Identification Module, SIM/WIM) als ein Authentifizierungstoken. Der Diensteanbieter, d.h. der Anbieter des Video-Streaming-Dienstes, nimmt zuerst mit dem ISP betreffs einer Authentifizierungserweiterung Kontakt auf. Der ISP kann, da er normalerweise keine SIMs und Mobiltelefone verwaltet, sondern wahrscheinlich nur Passwortlisten, kann dem strengeren ASProf nicht genügen. Er kann dem Diensteanbieter ein schwächeres ASProf anbieten, doch der Diensteanbieter lehnt dies ab. Der Diensteanbieter nimmt anschließend mit dem Mobilfunkbetreiber des Benutzers Kontakt auf, welcher von dem Client in der ursprünglichen Dienstanforderung als ein potentieller Identitätsanbieter spezifiziert worden sein kann. Der Mobilfunkbetreiber als ein Identitätsanbieter ist in der Lage, dem spezifizierten, d.h. den Besitz eines speziellen SIM/WIM sowie die Kenntnis eines PIN-Codes erfordernden ASProf zu genügen. Er sendet die Assertion der stärkeren Authentifizierung an den Diensteanbieter, so dass der Benutzer dann den Streaming-Dienst benutzen kann.
  • Es ist nicht notwendig, jedes Mal, wenn ein ASProf von einem Identitätsanbieter an einen Diensteanbieter oder umgekehrt gesendet wird, explizit die vollständige Menge von Attributen des ASProf aufzuführen. Dementsprechend müssen auch Relationen zwischen ASProfs oder sogar der vollständige Graph nicht in ihrer Gesamtheit gesendet werden. Stattdessen können Verweise (URIs) sowie Aktualisierungen verwendet werden, um die Menge der Daten zu reduzieren, die ausgetauscht werden, wie im Folgenden erläutert wird.
  • Ein ASProf kann aus einer Folge von Fragmenten bestehen, wobei jedes ein oder mehrere Attribute spezifiziert; vergleiche z.B. die XML-Beschreibung gemäß Tabelle A mit Fragmenten, welche <User_Credentials>, <Transportschicht_Sicherheit>, <Sicherheitsrichtlinien> und <Benutzerregistrierung> betreffen. Die Attribute aus den einzelnen Fragmenten ergänzen entweder einander, d.h. wenn sie nur in einem Fragment vorhanden sind, oder sie setzen einander außer Kraft, d.h. wenn sie in beiden Fragmenten vorhanden sind. Im Falle einer Außerkraftsetzung muss eine Prioritätsvereinbarung auf der Basis der Reihenfolge der Fragmente festgelegt werden, d.h. nachfolgende Fragmente setzen vorhergehende außer Kraft, oder umgekehrt.
  • Ein Verweis, z.B. vorzugsweise ein URI, kann verwendet werden, um auf ein ASProf oder auf ein Fragment zu verweisen, das vorzugsweise eine semantische Teilmenge des vollständigen ASProf repräsentiert, anstatt explizit alle Attribute des betreffenden ASProf oder Fragments aufzuführen. Die Verwendung von Verweisen ermöglicht das Laden (Fetching) und Zwischenspeichern (Caching) und kann die Menge der zurück und vor gesendeten Daten wesentlich reduzieren. Wenn zum Beispiel ein Diensteanbieter häufig einen gewissen Identitätsanbieter verwendet, welcher für einen gewissen Zeitraum dasselbe ASProf verwendet, besteht keine Notwendigkeit, dass jedes Mal, wenn innerhalb des besagten gewissen Zeitraums ein neuer Benutzer authentifiziert wird, das ASProf explizit zwischen dem Diensteanbieter und dem Identitätsanbieter ausgetauscht wird.
  • Die Verwendung von Aktualisierungen von ASProfs im Sinne einer Delta-Aktualisierung, die sich auf Unterschiede zwischen existierenden ASProfs und neueren ASProfs bezieht, kann die Datenmenge, die ausgetauscht wird, zusätzlich reduzieren. Ein Aktualisierungs-ASProf ist ein neueres ASProf, welches entweder ein existierendes ASProf ergänzt oder einige seiner Attribute außer Kraft setzt. Auch Aktualisierungs-Fragmente oder Aktualisierungs-Attribute sind möglich. Zum Beispiel ist ein Benutzer bei einem Diensteanbieter von einem Identitätsanbieter unter Verwendung einer Passwort-Überprüfung authentifiziert worden. Für eine gewisse Benutzer-Interaktion ist eine Authentifizierunga-Aktualisierung erforderlich, wobei der einzige Unterschied gegenüber dem zuvor verwendeten ASProf ist, dass eine kürzere Lebensdauer für die Passwortüberprüfung spezifiziert ist. In diesem Falle ist es natürlich effizienter, einen Verweis auf das zuvor verwendete ASProf zu senden, plus ein einziges Attribut, welches das abweichende Lebensdauer-Attribut spezifiziert, als einen Verweis auf ein neues ASProf zu senden, welches der empfangende Teilnehmer vollständig laden und zwischenspeichern müsste.
  • Das vorgeschlagene Verfahren wird auch durch Vorrichtungen wie Server verkörpert, die einem Diensteanbieter oder einem Identitätsanbieter zugeordnet sind, oder durch einen Proxy, oder eine Client-Vorrichtung. Eine solche Vorrichtung umfasst mindestens eine Empfangseinheit R zum Empfangen von Nachrichten M2, eine Sendeeinheit T zum Senden von Nachrichten M1 und eine Verarbeitungseinheit P zum Verarbeiten von Nachrichten und Informationen, und vorzugsweise eine Datenbank D zum Speichern von Informationen. Ein Beispiel für eine solche Vorrichtung ist in 12 dargestellt, welche die Einheiten R, T, P, D und Nachrichten M1, M2 und Verbindungen PR, PT, PT zum Austauschen von Informationen und Nachrichten zwischen den einzelnen Einheiten R, T, P, D zeigt. Die Vorrichtung DEV ist ein Beispiel für eine Vorrichtung, welche von dem Diensteanbieter, dem Identitätsanbieter oder dem Benutzer als Client-Vorrichtung zur Implementierung des Verfahrens verwendet werden kann.
  • Beispiele für Vorrichtungen und Verbindungen zum Austauschen von Nachrichten und Informationen zwischen Vorrichtungen zur Ausführung des Authentifizierungsverfahrens sind in 13, 14 und 15 für Rückkanal-, Frontkanal- bzw. hybride Rückkanal-/Frontkanal-Kommunikation angegeben. Die Vorrichtungen können so aufgebaut sein, wie in Verbindung mit 12 dargestellt und beschrieben wurde.
  • 13 zeigt einen Client D12, einen Diensteanbieter D10 und einen Identitätsanbieter D11 sowie Verbindungen CON10, CON11, CON12 zwischen den drei Teilnehmern zur Authentifizierung des Clients D12 bei dem Diensteanbieter D10 mittels Frontkanal-Kommunikation. Die Kommunikation zwischen dem Client D12 und dem Diensteanbieter D10 erfolgt über die Verbindung CON10, die Kommunikation zwischen dem Diensteanbieter D10 und dem Identitätsanbieter D11 erfolgt über die Verbindung CON11, und die Kommunikation zwischen dem Identitätsanbieter D11 und dem Client D12 erfolgt über die Verbindung CON12. Beispiele für Informationen und Nachrichten, die zwischen den drei Teilnehmern über die Verbindungen CON10, CON11, CON12 ausgetauscht werden, sind zum Beispiel in 3 zu finden, nämlich Dienstanforderung (Nachricht 1a), Aufforderung zur Authentifizierung (Nachricht 1b), Benutzerkennung und Verweis auf Identitätsanbieter (Nachricht 1c) und Dienstsitzung über die Verbindung CON10, das gewünschte ASProf und die Benutzerkennung (Nachricht 2) und die Assertion der Benutzerauthentifizierung (Nachricht 3d) über die Verbindung CON11 und die Anforderung von User Credentials (Nachricht 3b) sowie die Übermittlung der User Credentials (Nachricht 3c) über die Verbindung CON12. Die Verbindungen CON10, CON11, CON12 können stationäre Verbindungen sein, müssen es jedoch nicht; z.B. kann die Verbindung CON12 über Kurzmitteilungsdienste (Short Message Services, SMS) realisiert werden, wenn der Client D12 ein Mobiltelefon ist.
  • 14 zeigt einen Client D22, einen Diensteanbieter D20 und einen Identitätsanbieter D21 sowie Verbindungen CON20, CON21 zwischen den drei Teilnehmern zur Authentifizierung des Clients D22 bei dem Diensteanbieter D20 mittels Frontkanal-Kommunikation. Anders als in 11 existiert keine direkte Verbindung zwischen dem Diensteanbieter D20 und dem Identitätsanbieter D21. Stattdessen erfolgt die Kommunikation zwischen dem Diensteanbieter D20 und dem Identitätsanbieter D21 über den Client D22, in dem Sinne, dass die Informationen, die zwischen dem Diensteanbieter D20 und dem Identitätsanbieter D21 auszutauschen sind, von dem Client D22 weitergeleitet werden. Beispiele für Informationen und Nachrichten, die zwischen den drei Teilnehmern über die Verbindungen CON20 und CON21 ausgetauscht werden, sind in 4 zu finden, nämlich Dienstanforderung (Nachricht 1a), Aufforderung zur Authentifizierung (Nachricht 1b), Benutzerkennung und Verweis auf Identitätsanbieter (Nachricht 1c) und Dienstsitzung werden über die Verbindung CON20 gesendet. Dementsprechend werden die Anforderung von User Credentials (3b) und die User Credentials über die Verbindung CON21 gesendet. Jedoch werden das gewünschte ASProf und die Benutzerkennung, die in der Aufforderung zur Authentifizierung enthalten sind (Nachrichten 42a, 42b), über die Verbindungen CON20 und CON21 von dem Diensteanbieter D20 über den Client D22 an den Identitätsanbieter D21 gesendet. Eine entsprechende Weiterleitung wird für die Assertion der Benutzerauthentifizierung (Nachrichten 43d, 43e) durchgeführt, die über die Verbindungen CON21 und CON20 von dem Identitätsanbieter D21 über den Client D22 an den Diensteanbieter D20 gesendet wird.
  • 15 zeigt eine Hybrid-Implementierung mit Verwendung eines Proxy D31 zum Emulieren einer Frontkanal-Implementierung. Zur Authentifizierung des Benutzers des Clients D33 bei einem Dienst des Diensteanbieters D30 sendet der Client D33 eine Dienstanforderung über die Verbindung CON30 an den Diensteanbieter D30. Der Diensteanbieter D30 antwortet mit einer Aufforderung zur Benutzerauthentifizierung über die Verbindung C30 an den Client, und der Client D33 liefert dem Diensteanbieter D30 über die Verbindung CON30 die Benutzerkennung und optional einen Verweis auf den Identitätsanbieter D32. Für die Kommunikation zwischen dem Diensteanbieter D30 und dem Identitätsanbieter D32, z.B. für das Senden der Benutzerkennung und des gewünschten ASProf oder für die Assertion der Benutzerauthentifizierung, ist ein Proxy D31 zwischen dem Diensteanbieter D30 und dem Identitätsanbieter D32 zwischengeschaltet. Informationen können von dem Diensteanbieter D30 zu dem Identitätsanbieter D32 und umgekehrt unter Verwendung der Verbindungen CON31 und CON32 über den Proxy D31 gesendet werden. Für die Anforderung von User Credentials und die Übermittlung von User Credentials kann die Verbindung CON35 verwendet werden. Stattdessen können auch die Verbindung CON32 und die Verbindung CON34 für die Anforderung und die Übermittlung von User Credentials verwendet werden. Weitere Informationen können zwischen dem Proxy D31 und dem Client D33 über die Verbindung CON34 ausgetauscht werden.
  • Das Verfahren gemäß der Erfindung wird außerdem durch ein oder mehrere Computerprogramme verkörpert, die auf Vorrichtungen geladen werden können, die einem Diensteanbieter, Identitätsanbieter, Proxy oder Client zugeordnet sind. Das eine oder die mehreren Computerprogramme umfassen Abschnitte von Softwarecodes, um das Verfahren, so wie es oben beschrieben wurde, zu implementieren. Das eine oder die mehreren Computerprogramme können auf einem maschinenlesbaren Medium gespeichert sein. Das maschinenlesbare Medium kann ein nichtflüchtiger oder wiederbeschreibbarer Speicher innerhalb eines Servers oder ein Server sein oder extern angeordnet sein. Das Computerprogramm kann auch zum Beispiel über ein Kabel oder eine drahtlose Verbindung als eine Folge von Signalen zu einem Server übertragen werden.
  • Das vorgeschlagene Verfahren kann so angepasst werden, dass es in 2G und 3G Mobilkommunikationssystemen wie GPRS bzw. UMTS verwendet werden kann. Es kann auch für eine Authentifizierung bei Diensten in Festnetzen wie dem Internet und Kombinationen von Festnetzen und drahtlosen Netzen einschließlich von drahtlosen Lokalnetzen (Wireless Local Area Networks, WLAN) angewendet werden. Von dem Benutzer können mobile und stationäre Client-Terminals verwendet werden. Die einem Diensteanbieter, Identitätsanbieter oder Proxy zugeordneten Server sind normalerweise stationär in einem Netz. Das vorgeschlagene Verfahren kann jedoch auch für sich bewegende, nichtstationäre Server angewendet werden. Beispiele für Server sind Personalcomputer (PCs) oder Laptopcomputer.
  • Im Folgenden werden einige der Vorteile der Erfindung zusammengefasst:
    Anstelle des Vorhandenseins fester Beziehungen zwischen Diensteanbietern und Identitätsanbietern mit statischen Authentifizierungs-Sicherheitsrichtlinien kann die Erfindung Ad-hoc-Verhandlung und Erweiterung von Authentifizierungs-Sicherheitsprofilen ermöglichen. Für eine Ad-hoc-Verhandlung ist keine vorherige Vereinbarung zwischen einem Diensteanbieter und einem Identitätsanbieter über ASProfs erforderlich.
  • Ferner können verschiedene Typen von Diensten und Transaktionen sehr unterschiedliche Anforderungen an den Grad der Gewissheit darüber aufweisen, dass ein Benutzer derjenige ist, der er zu sein behauptet. Ebenso gewährleisten unterschiedliche Authentifizierungsmechanismen und Sicherheits-Infrastrukturen unterschiedliche Gewissheitsgrade. Das vorgeschlagene Verfahren unterstützt diese unterschiedlichen Gewissheitsgrade und überwindet daher Einschränkungen, die bei binären Authentifizierungskonzepten gewöhnlich vorhanden sind.
  • Ein anderer Vorteil ist, dass die Erfindung ein flexibles Modell bereitstellt, welches spontane Änderungen von Richtlinien sowohl auf der Seite des Diensteanbieters als auch auf der des Identitätsanbieters ermöglicht. Wenn sich Richtlinien und Sicherheitsmerkmale ändern, kann die Out-of-Band-Kommunikation zwischen Diensteanbieter und Identitätsanbieter auf ein Minimum begrenzt werden.
  • Ferner ermöglicht das Authentifizierungsverfahren, komplexe Spezifikationen von ASProfs zu handhaben, d.h. unterschiedliche Typen von Attributen wie Fingerabdruck-Erkennung und Passwort können in Bezug auf die Stärke der Authentifizierungssicherheit verglichen werden. Ferner können auch Kombinationen von verschiedenen Attributen verhandelt werden, was das vorgeschlagene Verfahren sogar noch flexibler macht.
  • Außerdem versetzt das Authentifizierungsverfahren den Dienst bzw. den Diensteanbieter in die Lage, als die Richtlinienentscheidungs- und Richtliniendurchsetzungs-Instanz zu agieren, welche letztendlich die Entscheidung über die Authentifizierung trifft. Für diesen für den Diensteanbieter günstigen Fall kann die Erfindung derart implementiert werden, dass der Identitätsanbieter den Dienst des Validierens von User Credentials anbietet und der Identitätsanbieter vorzugsweise nur am Aufbau der Sitzung oder bei Authentifizierungserweiterungen beteiligt ist. Dass der Identitätsanbieter ansonsten während einer Sitzung nicht benötigt wird, verringert demzufolge die Belastung des Identitätsanbieters und die Komplexität seines Sitzungsmanagements, und es verbessert die Skalierbarkeit im Vergleich zu Authentifizierungsverfahren nach dem Stand der Technik mit einem zwischengeschalteten Identitätsanbieter.

Claims (19)

  1. Verfahren zur Authentifizierung eines Benutzers bei einem Dienst eines Diensteanbieters (SP), welches die folgenden Schritte umfasst: – Anfordern eines Zugangs für den Benutzer zu dem Dienst des Diensteanbieters (SP), – Auswählen eines oder mehrerer Authentifizierungs-Sicherheitsprofile durch den Diensteanbieter (SP), welche wenigstens ein Sicherheitsattribut zum Spezifizieren einer Authentifizierungs-Sicherheitsanforderung für die Authentifizierung des Benutzers bei dem Dienst umfassen, – Senden einer Angabe des einen oder der mehreren ausgewählten Authentifizierungs-Sicherheitsprofile und einer Benutzerkennung, die den Benutzer identifiziert, an einen Identitätsanbieter (IdP1) zum Anfordern der Authentifizierung des Benutzers durch den Identitätsanbieter (IdP1), – Authentifizieren des Benutzers auf der Basis der Benutzerkennung und eines des einen oder der mehreren ausgewählten Authentifizierungs-Sicherheitsprofile, und – Senden einer Assertion, welche die Authentifizierung des Benutzers anzeigt, an den Diensteanbieter (SP).
  2. Verfahren nach Anspruch 1, wobei das eine Authentifizierungs-Sicherheitsprofil, auf dessen Basis die Authentifizierung ausgeführt wird, von dem Identitätsanbieter (IdP1) aus den ausgewählten Authentifizierungs-Sicherheitsprofilen ausgewählt wird.
  3. Verfahren nach Anspruch 1 oder 2, wobei die Assertion durch eine Angabe des Authentifizierungs-Sicherheitsprofils ergänzt wird, auf dessen Basis die Authentifizierung ausgeführt wird, und wobei das angegebene Authentifizierungs-Sicherheitsprofil von dem Diensteanbieter (SP) auf Akzeptanz geprüft wird.
  4. Verfahren zur Authentifizierung eines Benutzers bei einem Dienst eines Diensteanbieters (SP), welches die folgenden Schritte umfasst: – Anfordern eines Zugangs für den Benutzer zu dem Dienst des Diensteanbieters (SP), – Senden einer Benutzerkennung, die den Benutzer identifiziert, an einen Identitätsanbieter (IdP1) zum Anfordern der Authentifizierung des Benutzers durch den Identitätsanbieter (IdP1), – Authentifizieren des Benutzers auf der Basis der Benutzerkennung und eines Authentifizierungs-Sicherheitsprofils, das wenigstens ein Sicherheitsattribut umfasst, – Senden einer Assertion, welche die Authentifizierung des Benutzers anzeigt, an den Diensteanbieter (SP), wobei die Assertion durch eine Angabe des Authentifizierungs-Sicherheitsprofils ergänzt wird, und – Prüfen des angegebenen Authentifizierungs-Sicherheitsprofils durch den Diensteanbieter (SP) auf Akzeptanz.
  5. Verfahren nach einem der vorhergehenden Ansprüche, welches ferner den Schritt des Empfangens der Benutzerkennung und eines Verweises auf den Identitätsanbieter (IdP1) von einer Benutzervorrichtung, in Reaktion auf eine von dem Diensteanbieter (SP) an die Benutzervorrichtung gesendete Authentifizierungsaufforderung, bei dem Diensteanbieter (SP) umfasst.
  6. Verfahren nach einem der vorhergehenden Ansprüche, welches ferner den Schritt des Gewährens eines Zugangs zu dem Dienst auf der Basis der Assertion umfasst.
  7. Verfahren nach einem der Ansprüche 3 bis 5, welches ferner den Schritt des Gewährens eines Zugangs zu dem Dienst auf der Basis der Assertion und der Prüfung auf Akzeptanz umfasst.
  8. Vorrichtung, die einem Diensteanbieter (SP) zugeordnet ist, wobei die Vorrichtung eine Empfangseinheit zum Empfangen von Nachrichten, eine Sendeeinheit zum Senden von Nachrichten und eine Verarbeitungseinheit zum Verarbeiten von Nachrichten und Informationen umfasst, wobei die Vorrichtung in der Lage ist, – eine Anforderung eines Zugangs eines Benutzers zu einem Dienst des Diensteanbieters (SP) zu empfangen, – ein oder mehrere Authentifizierungs-Sicherheitsprofile auszuwählen, welche wenigstens ein Sicherheitsattribut zum Spezifizieren einer Authentifizierungs-Sicherheitsanforderung für eine Authentifizierung des Benutzers bei dem Dienst umfassen, – eine Angabe des einen oder der mehreren ausgewählten Authentifizierungs-Sicherheitsprofile und eine Benutzerkennung, die den Benutzer identifiziert, an einen Identitätsanbieter (IdP1) zum Anfordern der Authentifizierung des Benutzers durch den Identitätsanbieter (IdP1) zu senden, und – eine Assertion zu empfangen, welche die Authentifizierung des Benutzers durch den Identitätsanbieter (IdP1) anzeigt.
  9. Vorrichtung nach Anspruch 8, wobei die Vorrichtung in der Lage ist, eine Angabe des Authentifizierungs-Sicherheitsprofils zu empfangen, auf dessen Basis die Authentifizierung des Benutzers durch den Identitätsanbieter (IdP1) ausgeführt wird, und wobei die Vorrichtung ferner in der Lage ist, das angegebene Authentifizierungs-Sicherheitsprofil auf Akzeptanz zu prüfen.
  10. Vorrichtung, die einem Diensteanbieter (SP) zugeordnet ist, wobei die Vorrichtung eine Empfangseinheit zum Empfangen von Nachrichten, eine Sendeeinheit zum Senden von Nachrichten und eine Verarbeitungseinheit zum Verarbeiten von Nachrichten und Informationen umfasst, wobei die Vorrichtung in der Lage ist, – eine Anforderung eines Zugangs eines Benutzers zu einem Dienst des Diensteanbieters (SP) zu empfangen, – eine Benutzerkennung, die den Benutzer identifiziert, an einen Identitätsanbieter (IdP1) zum Anfordern einer Authentifizierung des Benutzers durch den Identitätsanbieter (IdP1) zu senden, – eine Assertion, welche die Authentifizierung des Benutzers anzeigt, von dem Identitätsanbieter (IdP1) zu empfangen, wobei die Assertion durch eine Angabe des Authentifizierungs-Sicherheitsprofils ergänzt wird, das wenigstens ein Sicherheitsattribut umfasst, und – das angegebene Authentifizierungs-Sicherheitsprofi auf Akzeptanz zu prüfen.
  11. Vorrichtung nach einem der Ansprüche 8 bis 10, wobei die Vorrichtung in der Lage ist, von einer Benutzervorrichtung in Reaktion auf eine von der dem Diensteanbieter (SP) zugeordneten Vorrichtung an die Benutzervorrichtung gesendete Authentifizierungsaufforderung die Benutzerkennung und einen Verweis auf den Identitätsanbieter (IdP1) zu empfangen.
  12. Vorrichtung nach einem der Ansprüche 8 bis 11, wobei die Vorrichtung in der Lage ist, auf der Basis der Assertion einen Zugang zu dem Dienst zu gewähren.
  13. Vorrichtung nach einem der Ansprüche 9 bis 11, wobei die Vorrichtung in der Lage ist, auf der Basis der Assertion und der Prüfung auf Akzeptanz einen Zugang zu dem Dienst zu gewähren.
  14. Vorrichtung, die einem Identitätsanbieter (IdP1) zugeordnet ist, wobei die Vorrichtung eine Empfangseinheit zum Empfangen von Nachrichten, eine Sendeeinheit zum Senden von Nachrichten und eine Verarbeitungseinheit zum Verarbeiten von Nachrichten und Informationen umfasst, wobei die Vorrichtung in der Lage ist, – eine Aufforderung zur Authentifizierung eines Benutzers zu empfangen, wobei die Aufforderung umfasst: eine Benutzerkennung, die den Benutzer für den Identitätsanbieter (IdP1) identifiziert, und eine Angabe eines oder mehrerer Authentifizierungs-Sicherheitsprofile, die wenigstens ein Sicherheitsattribut umfassen, das eine Authentifizierungs-Sicherheitsanforderung des Diensteanbieters (SP) für die Authentifizierung des Benutzers bei einem Dienst des Diensteanbieters (SP) spezifiziert, – den Benutzer auf der Basis der Benutzerkennung und eines des einen oder der mehreren Authentifizierungs-Sicherheitsprofile zu authentifizieren, und – eine Assertion, welche dem Diensteanbieter (SP) die Authentifizierung des Benutzers anzeigt, zu senden.
  15. Vorrichtung nach Anspruch 14, wobei die Vorrichtung in der Lage ist, das eine Authentifizierungs-Sicherheitsprofil, auf dessen Basis die Authentifizierung ausgeführt wird, aus den Authentifizierungs-Sicherheitsprofilen auszuwählen.
  16. Vorrichtung nach Anspruch 14 oder 15, wobei die Vorrichtung in der Lage ist, die Assertion durch eine Angabe des Authentifizierungs-Sicherheitsprofils, auf dessen Basis die Authentifizierung ausgeführt wird, zu ergänzen.
  17. Vorrichtung, die einem Identitätsanbieter (IdP1) zugeordnet ist, wobei die Vorrichtung eine Empfangseinheit zum Empfangen von Nachrichten, eine Sendeeinheit zum Senden von Nachrichten und eine Verarbeitungseinheit zum Verarbeiten von Nachrichten und Informationen umfasst, wobei die Vorrichtung in der Lage ist, – eine Aufforderung zur Authentifizierung eines Benutzers zu empfangen, wobei die Aufforderung eine Benutzerkennung umfasst, die den Benutzer für den Identitätsanbieter (IdP1) identifiziert, – den Benutzer auf der Basis der Benutzerkennung und eines Authentifizierungs-Sicherheitsprofils, das wenigstens ein Sicherheitsattribut umfasst, zu authentifizieren, und – eine Assertion, welche dem Diensteanbieter (SP) die Authentifizierung des Benutzers anzeigt, zu senden, wobei die Assertion durch eine Angabe des Authentifizierungs-Sicherheitsprofils ergänzt wird, auf dessen Basis die Authentifizierung des Benutzers ausgeführt wird.
  18. Computerprogramm, das auf eine Vorrichtung geladen werden kann, die einem Diensteanbieter (SP) zugeordnet ist, wobei das Computerprogramm Code umfasst, der dazu geeignet ist, die Schritte des Verfahrens nach einem der Ansprüche 1 bis 7 auszuführen, soweit sie den Diensteanbieter (SP) betreffen.
  19. Computerprogramm, das auf eine Vorrichtung geladen werden kann, die einem Identitätsanbieter (IdP1) zugeordnet ist, wobei das Computerprogramm Code umfasst, der dazu geeignet ist, die Schritte des Verfahrens nach einem der Ansprüche 1 bis 7 auszuführen, soweit sie den Identitätsanbieter (IdP1) betreffen.
DE60314871T 2002-05-24 2003-05-23 Verfahren zur authentifizierung eines anwenders bei einem zugang zu einem dienst eines diensteanbieters Expired - Lifetime DE60314871T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP02011440 2002-05-24
EP02011440 2002-05-24
PCT/EP2003/005421 WO2003100544A2 (en) 2002-05-24 2003-05-23 Method for authenticating a user to a service of a service provider

Publications (2)

Publication Number Publication Date
DE60314871D1 DE60314871D1 (de) 2007-08-23
DE60314871T2 true DE60314871T2 (de) 2008-03-13

Family

ID=29558288

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60314871T Expired - Lifetime DE60314871T2 (de) 2002-05-24 2003-05-23 Verfahren zur authentifizierung eines anwenders bei einem zugang zu einem dienst eines diensteanbieters

Country Status (9)

Country Link
US (2) US20060053296A1 (de)
EP (1) EP1508236B1 (de)
JP (1) JP4668610B2 (de)
KR (1) KR100989487B1 (de)
CN (1) CN1656773B (de)
AT (1) ATE367043T1 (de)
AU (1) AU2003245887A1 (de)
DE (1) DE60314871T2 (de)
WO (1) WO2003100544A2 (de)

Families Citing this family (239)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8026229B2 (en) 2001-08-13 2011-09-27 Sterix Limited Antitumor-active 2-alkoxyestradiol sulfamates
US7370347B2 (en) * 2003-06-27 2008-05-06 Sap Ag Authentication scheme system and method
US7526541B2 (en) * 2003-07-29 2009-04-28 Enterasys Networks, Inc. System and method for dynamic network policy management
EP1569405A1 (de) * 2004-02-27 2005-08-31 Telefonaktiebolaget LM Ericsson (publ) Technik zum Erstellen und Verknüpfen von Benutzerkonten in einem Kommunikationsnetzwerk
KR20060130717A (ko) 2004-03-05 2006-12-19 시큐어 시스템즈 리미티드 파티션 액세스 제어 시스템 및 파티션 액세스 제어 방법
US8914518B2 (en) * 2004-04-23 2014-12-16 International Business Machines Corporation Intermediary for satisfying a service requirement established by a service provider
US20050262100A1 (en) * 2004-05-19 2005-11-24 Bea Systems, Inc. System and method for context propagation in application servers and transaction-based systems
ES2264853B1 (es) * 2004-06-24 2007-12-16 Vodafone España, S.A. Sistema y metodo de asercion de identidades en una red de telecomunicaciones.
US8499153B2 (en) * 2004-06-24 2013-07-30 Nokia Corporation System and method of authenticating a user to a service provider
US7336773B2 (en) * 2004-07-21 2008-02-26 Nokia, Inc. Method and system for multi-mode communication with sender authentication
US20060059340A1 (en) * 2004-09-10 2006-03-16 Eldenmalm Jan P Method and system for dynamic authentication and authorization
US7613919B2 (en) * 2004-10-12 2009-11-03 Bagley Brian B Single-use password authentication
KR100639993B1 (ko) * 2004-12-07 2006-10-31 한국전자통신연구원 사용자 식별자 갱신 방법 및 그 시스템
US20060161616A1 (en) * 2005-01-14 2006-07-20 I Anson Colin Provision of services over a common delivery platform such as a mobile telephony network
GB2422218B (en) * 2005-01-14 2009-12-23 Hewlett Packard Development Co Provision of services over a common delivery platform such as a mobile telephony network
GB2422217B (en) 2005-01-14 2009-12-23 Hewlett Packard Development Co Provision of services over a common delivery platform such as a mobile telephony network
US7784092B2 (en) * 2005-03-25 2010-08-24 AT&T Intellectual I, L.P. System and method of locating identity providers in a data network
EP1710969A1 (de) * 2005-04-08 2006-10-11 Siemens Aktiengesellschaft Verfahren und Vorrichtung zur Übertragung von personalisiertem digitalen Inhalt von einem ersten Gebraucher auf einen Zweiten
US7657746B2 (en) * 2005-04-22 2010-02-02 Microsoft Corporation Supporting statements for credential based access control
AU2006269374C1 (en) 2005-07-12 2010-03-25 Massachusetts Institute Of Technology Wireless non-radiative energy transfer
US7825543B2 (en) 2005-07-12 2010-11-02 Massachusetts Institute Of Technology Wireless energy transfer
US7814330B2 (en) * 2005-08-01 2010-10-12 Oracle International Corporation Method and apparatus for facilitating multi-level computer system authentication
FR2891677A1 (fr) * 2005-10-05 2007-04-06 France Telecom Procede d'authentification d'un client, fournisseurs d'identites et de services, signaux de requete d'authentification et d'assertion d'authentification, et programmes d'ordinateur correspondants
US7797734B2 (en) * 2005-10-27 2010-09-14 Aurora Financial Systems, Inc. Systems and methods for user interface control
US7784085B2 (en) * 2005-12-08 2010-08-24 Oracle America, Inc. Enabling identity information exchange between circles of trust
WO2007085175A1 (fr) * 2006-01-24 2007-08-02 Huawei Technologies Co., Ltd. Procédé, système d'authentification et centre d'authentification reposant sur des communications de bout en bout dans le réseau mobile
US20080028453A1 (en) * 2006-03-30 2008-01-31 Thinh Nguyen Identity and access management framework
US20070255953A1 (en) * 2006-04-28 2007-11-01 Plastyc Inc. Authentication method and apparatus between an internet site and on-line customers using customer-specific streamed audio or video signals
FR2901436B1 (fr) 2006-05-19 2008-07-04 Airbus France Sas Dispositif de reception de messages, en particulier dans le cadre d'echanges securises de donnees, aeronef et procede associes
US8417791B1 (en) * 2006-06-30 2013-04-09 Google Inc. Hosted calling service
JP4611946B2 (ja) * 2006-08-10 2011-01-12 日本電信電話株式会社 利用者回線認証システム、利用者回線認証方法および利用者回線認証プログラム
JP5205380B2 (ja) 2006-08-22 2013-06-05 インターデイジタル テクノロジー コーポレーション アプリケーションおよびインターネットベースのサービスに対する信頼されるシングル・サインオン・アクセスを提供するための方法および装置
US8418235B2 (en) * 2006-11-15 2013-04-09 Research In Motion Limited Client credential based secure session authentication method and apparatus
US8375360B2 (en) * 2006-11-22 2013-02-12 Hewlett-Packard Development Company, L.P. Provision of services over a common delivery platform such as a mobile telephony network
US8689296B2 (en) * 2007-01-26 2014-04-01 Microsoft Corporation Remote access of digital identities
US8590027B2 (en) * 2007-02-05 2013-11-19 Red Hat, Inc. Secure authentication in browser redirection authentication schemes
US8689306B2 (en) * 2007-02-28 2014-04-01 Orange Method for the unique authentication of a user by service providers
US20080222714A1 (en) * 2007-03-09 2008-09-11 Mark Frederick Wahl System and method for authentication upon network attachment
US7870597B2 (en) * 2007-04-10 2011-01-11 Symantec Corporation Method and apparatus for managing digital identities through a single interface
DE102008013079B4 (de) 2007-03-28 2024-03-21 NortonLifeLock Inc. Verfahren und Anordnung zur Verwaltung digitaler Identitäten über eine einzige Schnittstelle
CN101291220B (zh) * 2007-04-16 2010-08-18 华为技术有限公司 一种身份安全认证的系统、装置及方法
US8572716B2 (en) 2007-04-23 2013-10-29 Microsoft Corporation Integrating operating systems with content offered by web based entities
US9421388B2 (en) 2007-06-01 2016-08-23 Witricity Corporation Power generation for implantable devices
US8805530B2 (en) 2007-06-01 2014-08-12 Witricity Corporation Power generation for implantable devices
US9003488B2 (en) 2007-06-06 2015-04-07 Datavalet Technologies System and method for remote device recognition at public hotspots
EP2158784A2 (de) * 2007-06-06 2010-03-03 Boldstreet Inc. Ferndienstzugriffssystem und verfahren
US20140355592A1 (en) 2012-11-01 2014-12-04 Datavalet Technologies System and method for wireless device detection, recognition and visit profiling
EP2224676B1 (de) 2007-07-27 2017-03-15 BlackBerry Limited Vorrichtung und Verfahren zur Koordination von drahtlosen Systemen
FI121646B (fi) * 2007-08-08 2011-02-15 Teliasonera Finland Oyj Menetelmä ja järjestelmä käyttäjäidentiteetin hallintaan
US20090064291A1 (en) * 2007-08-28 2009-03-05 Mark Frederick Wahl System and method for relaying authentication at network attachment
US20090089870A1 (en) * 2007-09-28 2009-04-02 Mark Frederick Wahl System and method for validating interactions in an identity metasystem
GB2456290B (en) * 2007-10-05 2011-03-30 Iti Scotland Ltd Distributed protocol for authorisation
US9471801B2 (en) * 2007-11-29 2016-10-18 Oracle International Corporation Method and apparatus to support privileges at multiple levels of authentication using a constraining ACL
NO20076550A (no) * 2007-12-19 2009-05-04 Fast Search & Transfer Asa Fremgangsmåte for å forbedre sikkerhet i prosedyrer for innlogging og tjenesteaksess
US9083680B2 (en) 2008-01-18 2015-07-14 Tekelec, Inc. Systems, methods, and computer readable media for application-level authentication of messages in a telecommunications network
CN101247223B (zh) * 2008-03-06 2010-06-09 西安西电捷通无线网络通信有限公司 一种基于可信第三方的实体双向鉴别方法
US8990896B2 (en) * 2008-06-24 2015-03-24 Microsoft Technology Licensing, Llc Extensible mechanism for securing objects using claims
US8250635B2 (en) * 2008-07-13 2012-08-21 International Business Machines Corporation Enabling authentication of openID user when requested identity provider is unavailable
US20100077457A1 (en) * 2008-09-23 2010-03-25 Sun Microsystems, Inc. Method and system for session management in an authentication environment
US9577436B2 (en) 2008-09-27 2017-02-21 Witricity Corporation Wireless energy transfer for implantable devices
US9184595B2 (en) 2008-09-27 2015-11-10 Witricity Corporation Wireless energy transfer in lossy environments
US9396867B2 (en) 2008-09-27 2016-07-19 Witricity Corporation Integrated resonator-shield structures
US9106203B2 (en) * 2008-09-27 2015-08-11 Witricity Corporation Secure wireless energy transfer in medical applications
US9601266B2 (en) 2008-09-27 2017-03-21 Witricity Corporation Multiple connected resonators with a single electronic circuit
US8957549B2 (en) 2008-09-27 2015-02-17 Witricity Corporation Tunable wireless energy transfer for in-vehicle applications
US8497601B2 (en) 2008-09-27 2013-07-30 Witricity Corporation Wireless energy transfer converters
US8912687B2 (en) 2008-09-27 2014-12-16 Witricity Corporation Secure wireless energy transfer for vehicle applications
US9160203B2 (en) 2008-09-27 2015-10-13 Witricity Corporation Wireless powered television
US9035499B2 (en) 2008-09-27 2015-05-19 Witricity Corporation Wireless energy transfer for photovoltaic panels
US8933594B2 (en) 2008-09-27 2015-01-13 Witricity Corporation Wireless energy transfer for vehicles
US9601270B2 (en) 2008-09-27 2017-03-21 Witricity Corporation Low AC resistance conductor designs
US8947186B2 (en) 2008-09-27 2015-02-03 Witricity Corporation Wireless energy transfer resonator thermal management
US9065423B2 (en) 2008-09-27 2015-06-23 Witricity Corporation Wireless energy distribution system
US8907531B2 (en) 2008-09-27 2014-12-09 Witricity Corporation Wireless energy transfer with variable size resonators for medical applications
US9105959B2 (en) 2008-09-27 2015-08-11 Witricity Corporation Resonator enclosure
US20100259110A1 (en) * 2008-09-27 2010-10-14 Kurs Andre B Resonator optimizations for wireless energy transfer
US9246336B2 (en) 2008-09-27 2016-01-26 Witricity Corporation Resonator optimizations for wireless energy transfer
US9515494B2 (en) 2008-09-27 2016-12-06 Witricity Corporation Wireless power system including impedance matching network
US8643326B2 (en) 2008-09-27 2014-02-04 Witricity Corporation Tunable wireless energy transfer systems
US9544683B2 (en) 2008-09-27 2017-01-10 Witricity Corporation Wirelessly powered audio devices
US9601261B2 (en) * 2008-09-27 2017-03-21 Witricity Corporation Wireless energy transfer using repeater resonators
US9318922B2 (en) 2008-09-27 2016-04-19 Witricity Corporation Mechanically removable wireless power vehicle seat assembly
US8901779B2 (en) 2008-09-27 2014-12-02 Witricity Corporation Wireless energy transfer with resonator arrays for medical applications
US8963488B2 (en) 2008-09-27 2015-02-24 Witricity Corporation Position insensitive wireless charging
US20110043049A1 (en) * 2008-09-27 2011-02-24 Aristeidis Karalis Wireless energy transfer with high-q resonators using field shaping to improve k
US8937408B2 (en) 2008-09-27 2015-01-20 Witricity Corporation Wireless energy transfer for medical applications
US8928276B2 (en) 2008-09-27 2015-01-06 Witricity Corporation Integrated repeaters for cell phone applications
US8922066B2 (en) 2008-09-27 2014-12-30 Witricity Corporation Wireless energy transfer with multi resonator arrays for vehicle applications
US9093853B2 (en) 2008-09-27 2015-07-28 Witricity Corporation Flexible resonator attachment
US8946938B2 (en) 2008-09-27 2015-02-03 Witricity Corporation Safety systems for wireless energy transfer in vehicle applications
US8598743B2 (en) 2008-09-27 2013-12-03 Witricity Corporation Resonator arrays for wireless energy transfer
US8901778B2 (en) 2008-09-27 2014-12-02 Witricity Corporation Wireless energy transfer with variable size resonators for implanted medical devices
US8772973B2 (en) 2008-09-27 2014-07-08 Witricity Corporation Integrated resonator-shield structures
US20110074346A1 (en) * 2009-09-25 2011-03-31 Hall Katherine L Vehicle charger safety system and method
US20100277121A1 (en) * 2008-09-27 2010-11-04 Hall Katherine L Wireless energy transfer between a source and a vehicle
US9744858B2 (en) 2008-09-27 2017-08-29 Witricity Corporation System for wireless energy distribution in a vehicle
US8482158B2 (en) 2008-09-27 2013-07-09 Witricity Corporation Wireless energy transfer using variable size resonators and system monitoring
CN101582792A (zh) * 2008-09-28 2009-11-18 华为技术有限公司 一种安全状态重评估的方法、系统及装置
EP2345100B1 (de) 2008-10-01 2018-12-05 Massachusetts Institute of Technology Effiziente nahfeld-drahtlosenergieübertragung anhand adiabatischer systemveränderungen
EP2351308A1 (de) * 2008-10-08 2011-08-03 Nokia Siemens Networks Oy Verfahren zur bereitstellung von zugang zu einem dienst
AU2009322102B2 (en) 2008-11-04 2015-02-19 Securekey Technologies Inc. System and methods for online authentication
AT507759B1 (de) * 2008-12-02 2013-02-15 Human Bios Gmbh Anforderungsbasiertes personenidentifikationsverfahren
JP5161053B2 (ja) * 2008-12-11 2013-03-13 日本電信電話株式会社 ユーザ認証方法、ユーザ認証システム、サービス提供装置、及び認証制御装置
JP5302665B2 (ja) * 2008-12-25 2013-10-02 日本電信電話株式会社 認証サーバ提示方法、サービス提供システム、サービス提供装置、およびサービス提供プログラム
JP2010157012A (ja) * 2008-12-26 2010-07-15 Nippon Telegr & Teleph Corp <Ntt> 認証システム、ユーザ端末接続サーバ装置、ユーザ端末装置、これらのプログラム
US9100222B2 (en) * 2008-12-31 2015-08-04 Sybase, Inc. System and method for mobile user authentication
US8380989B2 (en) 2009-03-05 2013-02-19 Sybase, Inc. System and method for second factor authentication
US8903434B2 (en) * 2008-12-31 2014-12-02 Sybase, Inc. System and method for message-based conversations
US9209994B2 (en) * 2008-12-31 2015-12-08 Sybase, Inc. System and method for enhanced application server
JP5802137B2 (ja) 2009-02-05 2015-10-28 ダブリューダブリューパス コーポレイションＷｗｐａｓｓ Ｃｏｒｐｏｒａｔｉｏｎ 安全なプライベート・データ記憶装置を有する集中型の認証システム、および方法
EP2401838B1 (de) 2009-02-19 2013-12-11 SecureKey Technologies Inc. Online-authentifizierungssystem und -verfahren
CN101730100B (zh) * 2009-03-17 2012-11-28 中兴通讯股份有限公司 身份提供实体授权服务的监管方法以及监管实体
US20100248779A1 (en) * 2009-03-26 2010-09-30 Simon Phillips Cardholder verification rule applied in payment-enabled mobile telephone
US10764748B2 (en) * 2009-03-26 2020-09-01 Qualcomm Incorporated Apparatus and method for user identity authentication in peer-to-peer overlay networks
US8370509B2 (en) * 2009-04-09 2013-02-05 Alcatel Lucent Identity management services provided by network operator
US7690032B1 (en) 2009-05-22 2010-03-30 Daon Holdings Limited Method and system for confirming the identity of a user
WO2011006231A1 (en) 2009-07-17 2011-01-20 Boldstreet Inc. Hotspot network access system and method
US8443202B2 (en) 2009-08-05 2013-05-14 Daon Holdings Limited Methods and systems for authenticating users
US7685629B1 (en) 2009-08-05 2010-03-23 Daon Holdings Limited Methods and systems for authenticating users
US7865937B1 (en) 2009-08-05 2011-01-04 Daon Holdings Limited Methods and systems for authenticating users
CN101645776B (zh) 2009-08-28 2011-09-21 西安西电捷通无线网络通信股份有限公司 一种引入在线第三方的实体鉴别方法
CN101674182B (zh) 2009-09-30 2011-07-06 西安西电捷通无线网络通信股份有限公司 引入在线可信第三方的实体公钥获取、证书验证及鉴别的方法及系统
WO2011066658A1 (en) * 2009-12-01 2011-06-09 Securekey Technologies Inc. System and methods for identity attribute validation
US9129086B2 (en) * 2010-03-04 2015-09-08 International Business Machines Corporation Providing security services within a cloud computing environment
WO2011116395A1 (en) * 2010-03-19 2011-09-22 Appbanc, Llc Streaming media for portable devices
US8826030B2 (en) * 2010-03-22 2014-09-02 Daon Holdings Limited Methods and systems for authenticating users
EP2553863A1 (de) * 2010-03-29 2013-02-06 Intel Corporation Verfahren und vorrichtung für administratorbetriebene profilaktualisierung
CN102238148B (zh) * 2010-04-22 2015-10-21 中兴通讯股份有限公司 身份管理方法及系统
US8326266B2 (en) * 2010-05-25 2012-12-04 Telefonaktiebolaget Lm Ericsson (Publ) Redundant credentialed access to a secured network
US9602168B2 (en) 2010-08-31 2017-03-21 Witricity Corporation Communication in wireless energy transfer systems
US20120084844A1 (en) * 2010-09-30 2012-04-05 Jeremy Ray Brown Federation credential reset
US8689004B2 (en) 2010-11-05 2014-04-01 Microsoft Corporation Pluggable claim providers
KR101580379B1 (ko) * 2011-03-23 2015-12-23 인터디지탈 패튼 홀딩스, 인크 네트워크 통신 보호 시스템 및 방법
US10168413B2 (en) 2011-03-25 2019-01-01 T-Mobile Usa, Inc. Service enhancements using near field communication
US9600679B2 (en) * 2011-04-29 2017-03-21 Micro Focus Software Inc. Techniques for resource operation based on usage, sharing, and recommendations with modular authentication
US8914636B2 (en) 2011-06-28 2014-12-16 Interdigital Patent Holdings, Inc. Automated negotiation and selection of authentication protocols
US9948145B2 (en) 2011-07-08 2018-04-17 Witricity Corporation Wireless power transfer for a seat-vest-helmet system
US9258344B2 (en) * 2011-08-01 2016-02-09 Intel Corporation Multi-hop single sign-on (SSO) for identity provider (IdP) roaming/proxy
CN102916933A (zh) * 2011-08-03 2013-02-06 腾讯科技（深圳）有限公司 通过第三方网站进行注册或登陆的方法和系统
CN108110907B (zh) 2011-08-04 2022-08-02 韦特里西提公司 可调谐无线电源架构
US10044713B2 (en) 2011-08-19 2018-08-07 Interdigital Patent Holdings, Inc. OpenID/local openID security
US9824199B2 (en) 2011-08-25 2017-11-21 T-Mobile Usa, Inc. Multi-factor profile and security fingerprint analysis
US8832798B2 (en) * 2011-09-08 2014-09-09 International Business Machines Corporation Transaction authentication management including authentication confidence testing
US8590018B2 (en) 2011-09-08 2013-11-19 International Business Machines Corporation Transaction authentication management system with multiple authentication levels
ES2558182T3 (es) 2011-09-09 2016-02-02 Witricity Corporation Detección de objetos extraños en sistemas de transferencia de energía inalámbricos
US20130062966A1 (en) 2011-09-12 2013-03-14 Witricity Corporation Reconfigurable control architectures and algorithms for electric vehicle wireless energy transfer systems
KR101310208B1 (ko) * 2011-10-13 2013-09-24 서울여자대학교 산학협력단 보안 요구사항의 우선순위 결정 방법
US9318257B2 (en) 2011-10-18 2016-04-19 Witricity Corporation Wireless energy transfer for packaging
KR20140085591A (ko) 2011-11-04 2014-07-07 위트리시티 코포레이션 무선 에너지 전송 모델링 툴
US9306635B2 (en) 2012-01-26 2016-04-05 Witricity Corporation Wireless energy transfer with reduced fields
US8718607B2 (en) 2012-04-12 2014-05-06 At&T Intellectual Property I, L.P. Anonymous customer reference services enabler
US9031539B2 (en) * 2012-04-12 2015-05-12 At&T Intellectual Property I, L.P. Anonymous customer reference client
US8682385B2 (en) 2012-05-11 2014-03-25 International Business Machines Corporation Managing third party transactions at a mobile operator
US8850187B2 (en) * 2012-05-17 2014-09-30 Cable Television Laboratories, Inc. Subscriber certificate provisioning
US9172694B2 (en) * 2012-05-22 2015-10-27 International Business Machines Corporation Propagating delegated authorized credentials through legacy systems
JP6066586B2 (ja) * 2012-05-22 2017-01-25 キヤノン株式会社 情報処理システム、その制御方法、およびそのプログラム。
US9343922B2 (en) 2012-06-27 2016-05-17 Witricity Corporation Wireless energy transfer for rechargeable batteries
TW201417598A (zh) * 2012-07-13 2014-05-01 Interdigital Patent Holdings 安全性關聯特性
US9203829B1 (en) * 2012-07-18 2015-12-01 Google Inc. Unified user login
US9287607B2 (en) 2012-07-31 2016-03-15 Witricity Corporation Resonator fine tuning
US8745718B1 (en) 2012-08-20 2014-06-03 Jericho Systems Corporation Delivery of authentication information to a RESTful service using token validation scheme
US10084595B2 (en) 2012-08-24 2018-09-25 At&T Intellectual Property I, L.P. Algorithm-based anonymous customer references
US9595378B2 (en) 2012-09-19 2017-03-14 Witricity Corporation Resonator enclosure
US9442778B2 (en) * 2012-10-01 2016-09-13 Salesforce.Com, Inc. Method and system for secured inter-application communication in mobile devices
CN109969007A (zh) 2012-10-19 2019-07-05 韦特里西提公司 无线能量传输系统中的外来物检测
JP6255858B2 (ja) * 2012-10-31 2018-01-10 株式会社リコー システム及びサービス提供装置
US9842684B2 (en) 2012-11-16 2017-12-12 Witricity Corporation Systems and methods for wireless power system with improved performance and/or ease of use
US8898769B2 (en) 2012-11-16 2014-11-25 At&T Intellectual Property I, Lp Methods for provisioning universal integrated circuit cards
US20140181939A1 (en) * 2012-12-14 2014-06-26 United States Postal Service Cloud computing exchange for identity proofing and validation
US9411925B2 (en) * 2014-04-14 2016-08-09 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. Simultaneously viewing multi paired schematic and layout windows on printed circuit board (PCB) design software and tools
US9857821B2 (en) 2013-08-14 2018-01-02 Witricity Corporation Wireless power transfer frequency adjustment
US9036820B2 (en) 2013-09-11 2015-05-19 At&T Intellectual Property I, Lp System and methods for UICC-based secure communication
US9319419B2 (en) * 2013-09-26 2016-04-19 Wave Systems Corp. Device identification scoring
US9208300B2 (en) * 2013-10-23 2015-12-08 At&T Intellectual Property I, Lp Apparatus and method for secure authentication of a communication device
US9240994B2 (en) 2013-10-28 2016-01-19 At&T Intellectual Property I, Lp Apparatus and method for securely managing the accessibility to content and applications
US9231940B2 (en) * 2013-12-16 2016-01-05 Verizon Patent And Licensing Inc. Credential linking across multiple services
US9780573B2 (en) 2014-02-03 2017-10-03 Witricity Corporation Wirelessly charged battery system
US9952266B2 (en) 2014-02-14 2018-04-24 Witricity Corporation Object detection for wireless energy transfer systems
JP6201835B2 (ja) * 2014-03-14 2017-09-27 ソニー株式会社 情報処理装置、情報処理方法及びコンピュータプログラム
JP6287401B2 (ja) * 2014-03-18 2018-03-07 富士ゼロックス株式会社 中継装置、システム及びプログラム
KR101856455B1 (ko) * 2014-03-31 2018-05-10 도이체 텔레콤 악티엔 게젤샤프트 데이터 보호 서비스의 가입자의 사용자 신원 및/또는 사용자 데이터를 보호 및/또는 익명화하기 위한 방법 및 시스템, 모바일 통신 네트워크, 프로그램 및 컴퓨터 프로그램 제품
US9842687B2 (en) 2014-04-17 2017-12-12 Witricity Corporation Wireless power transfer systems with shaped magnetic components
WO2015161035A1 (en) 2014-04-17 2015-10-22 Witricity Corporation Wireless power transfer systems with shield openings
US11297059B2 (en) * 2014-04-25 2022-04-05 Adobe Inc. Facilitating user-centric identity management
US9837860B2 (en) 2014-05-05 2017-12-05 Witricity Corporation Wireless power transmission systems for elevators
EP3140680B1 (de) 2014-05-07 2021-04-21 WiTricity Corporation Fremdkörpererkennung in systemen zur drahtlosen energieübertragung
WO2015196123A2 (en) 2014-06-20 2015-12-23 Witricity Corporation Wireless power transfer systems for surfaces
US9264419B1 (en) * 2014-06-26 2016-02-16 Amazon Technologies, Inc. Two factor authentication with authentication objects
US9842688B2 (en) 2014-07-08 2017-12-12 Witricity Corporation Resonator balancing in wireless power transfer systems
US10574091B2 (en) 2014-07-08 2020-02-25 Witricity Corporation Enclosures for high power wireless power transfer systems
US10382430B2 (en) * 2014-07-28 2019-08-13 Encryptier Co., Ltd. User information management system; user information management method; program, and recording medium on which it is recorded, for management server; program, and recording medium on which it is recorded, for user terminal; and program, and recording medium on which it is recorded, for service server
CN107111594A (zh) * 2014-09-24 2017-08-29 V5系统公司 动态数据管理
US9906497B2 (en) 2014-10-06 2018-02-27 Cryptzone North America, Inc. Multi-tunneling virtual network adapter
US9148408B1 (en) 2014-10-06 2015-09-29 Cryptzone North America, Inc. Systems and methods for protecting network devices
US10129031B2 (en) 2014-10-31 2018-11-13 Convida Wireless, Llc End-to-end service layer authentication
US10904234B2 (en) 2014-11-07 2021-01-26 Privakey, Inc. Systems and methods of device based customer authentication and authorization
US9813400B2 (en) * 2014-11-07 2017-11-07 Probaris Technologies, Inc. Computer-implemented systems and methods of device based, internet-centric, authentication
US9875468B2 (en) 2014-11-26 2018-01-23 Buy It Mobility Networks Inc. Intelligent authentication process
US9843217B2 (en) 2015-01-05 2017-12-12 Witricity Corporation Wireless energy transfer for wearables
KR102001753B1 (ko) * 2015-03-16 2019-10-01 콘비다 와이어리스, 엘엘씨 공개 키잉 메커니즘들을 사용한 서비스 계층에서의 종단간 인증
JP6386967B2 (ja) * 2015-04-30 2018-09-05 日本電信電話株式会社 認証方法及びシステム
EP3089497A1 (de) * 2015-04-30 2016-11-02 Gemalto Sa Verfahren, anforderervorrichtung, prüfervorrichtung und server zur prüfung von mindestens einem teil einer benutzerinformation
US9736165B2 (en) 2015-05-29 2017-08-15 At&T Intellectual Property I, L.P. Centralized authentication for granting access to online services
US9866543B2 (en) * 2015-06-03 2018-01-09 Paypal, Inc. Authentication through multiple pathways based on device capabilities and user requests
US10412585B2 (en) * 2015-09-28 2019-09-10 Guangdong Oppo Mobile Telecommunicaions Corp., Ltd. User identity authentication method and device
US10248899B2 (en) 2015-10-06 2019-04-02 Witricity Corporation RFID tag and transponder detection in wireless energy transfer systems
US9929721B2 (en) 2015-10-14 2018-03-27 Witricity Corporation Phase and amplitude detection in wireless energy transfer systems
US9736120B2 (en) 2015-10-16 2017-08-15 Cryptzone North America, Inc. Client network access provision by a network traffic manager
US9866519B2 (en) 2015-10-16 2018-01-09 Cryptzone North America, Inc. Name resolving in segmented networks
US10063110B2 (en) 2015-10-19 2018-08-28 Witricity Corporation Foreign object detection in wireless energy transfer systems
EP3365958B1 (de) 2015-10-22 2020-05-27 WiTricity Corporation Dynamische abstimmung in system zum drahtlosen energietransfer
US10075019B2 (en) 2015-11-20 2018-09-11 Witricity Corporation Voltage source isolation in wireless power transfer systems
US10129252B1 (en) * 2015-12-17 2018-11-13 Wells Fargo Bank, N.A. Identity management system
US10263473B2 (en) 2016-02-02 2019-04-16 Witricity Corporation Controlling wireless power transfer systems
US10412048B2 (en) 2016-02-08 2019-09-10 Cryptzone North America, Inc. Protecting network devices by a firewall
US9628444B1 (en) 2016-02-08 2017-04-18 Cryptzone North America, Inc. Protecting network devices by a firewall
WO2017139406A1 (en) 2016-02-08 2017-08-17 Witricity Corporation Pwm capacitor control
US10438209B2 (en) 2016-02-10 2019-10-08 Bank Of America Corporation System for secure routing of data to various networks from a process data network
US10178105B2 (en) * 2016-02-22 2019-01-08 Bank Of America Corporation System for providing levels of security access to a process data network
US9503452B1 (en) 2016-04-07 2016-11-22 Automiti Llc System and method for identity recognition and affiliation of a user in a service transaction
US9560015B1 (en) 2016-04-12 2017-01-31 Cryptzone North America, Inc. Systems and methods for protecting network devices by a firewall
US10325081B2 (en) * 2016-08-18 2019-06-18 Hrb Innovations, Inc. Online identity scoring
US10402796B2 (en) 2016-08-29 2019-09-03 Bank Of America Corporation Application life-cycle transition record recreation system
CN107171941A (zh) * 2017-06-01 2017-09-15 来三斤（厦门）网络科技有限公司 一种分享和社交模式的互联网供应链平台，方法和装置
WO2019006376A1 (en) 2017-06-29 2019-01-03 Witricity Corporation PROTECTION AND CONTROL OF WIRELESS POWER SYSTEMS
CN111886884B (zh) 2018-03-09 2023-03-24 上海诺基亚贝尔股份有限公司 用于通信中的认证的方法、设备和计算机可读介质
US20190390971A1 (en) * 2018-06-25 2019-12-26 Uber Technologies, Inc. Determining cumulative estimated time for requested services
US11316849B1 (en) * 2019-04-04 2022-04-26 United Services Automobile Association (Usaa) Mutual authentication system
US11582229B2 (en) * 2019-06-01 2023-02-14 Apple Inc. Systems and methods of application single sign on
EP3721603B1 (de) 2019-07-02 2021-12-08 Advanced New Technologies Co., Ltd. System und verfahren zur erzeugung dezentraler identifikatoren
CN111316303B (zh) 2019-07-02 2023-11-10 创新先进技术有限公司 用于基于区块链的交叉实体认证的系统和方法
SG11202003757TA (en) 2019-07-02 2020-05-28 Advanced New Technologies Co Ltd System and method for issuing verifiable claims
EP3688633A4 (de) 2019-07-02 2020-10-07 Alibaba Group Holding Limited System und verfahren zur verifizierung von verifizierbaren ansprüchen
CN111164594B (zh) 2019-07-02 2023-08-25 创新先进技术有限公司 用于将去中心化标识映射到真实实体的系统和方法
CN111213147B (zh) 2019-07-02 2023-10-13 创新先进技术有限公司 用于基于区块链的交叉实体认证的系统和方法
US11277497B2 (en) * 2019-07-29 2022-03-15 Tim Donald Johnson System for storing, processing, and accessing medical data
US11783022B2 (en) 2020-06-01 2023-10-10 Apple Inc. Systems and methods of account verification upgrade
JP2022044080A (ja) * 2020-09-07 2022-03-17 富士フイルムビジネスイノベーション株式会社 情報処理装置及びプログラム
US20220343014A1 (en) * 2021-04-22 2022-10-27 Soundhound, Inc. Api for service provider fulfillment of data privacy requests

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5610910A (en) * 1995-08-17 1997-03-11 Northern Telecom Limited Access to telecommunications networks in multi-service environment
US5724423A (en) * 1995-09-18 1998-03-03 Telefonaktiebolaget Lm Ericsson Method and apparatus for user authentication
US5740361A (en) * 1996-06-03 1998-04-14 Compuserve Incorporated System for remote pass-phrase authentication
US6505296B2 (en) * 1997-10-13 2003-01-07 Hewlett-Packard Company Emulated branch effected by trampoline mechanism
JPH11224236A (ja) * 1998-02-05 1999-08-17 Mitsubishi Electric Corp 遠隔認証システム
CN1110764C (zh) * 1998-11-23 2003-06-04 黎明网络有限公司 一种综合信息服务平台系统及其方法
US6226752B1 (en) * 1999-05-11 2001-05-01 Sun Microsystems, Inc. Method and apparatus for authenticating users
US6609198B1 (en) * 1999-08-05 2003-08-19 Sun Microsystems, Inc. Log-on service providing credential level change without loss of session continuity
US6892307B1 (en) * 1999-08-05 2005-05-10 Sun Microsystems, Inc. Single sign-on framework with trust-level mapping to authentication requirements
US6697806B1 (en) * 2000-04-24 2004-02-24 Sprint Communications Company, L.P. Access network authorization
WO2001082190A1 (en) * 2000-04-26 2001-11-01 Global Transaction Company Multi-tiered identity verification authority for e-commerce

Also Published As

Publication number Publication date
EP1508236A2 (de) 2005-02-23
JP4668610B2 (ja) 2011-04-13
KR20040105259A (ko) 2004-12-14
KR100989487B1 (ko) 2010-10-22
US20060053296A1 (en) 2006-03-09
CN1656773B (zh) 2010-04-28
ATE367043T1 (de) 2007-08-15
DE60314871D1 (de) 2007-08-23
WO2003100544A3 (en) 2004-03-11
WO2003100544A2 (en) 2003-12-04
US20140101743A1 (en) 2014-04-10
CN1656773A (zh) 2005-08-17
AU2003245887A8 (en) 2003-12-12
AU2003245887A1 (en) 2003-12-12
EP1508236B1 (de) 2007-07-11
JP2005535006A (ja) 2005-11-17

Similar Documents

Publication Publication Date Title
DE60314871T2 (de) Verfahren zur authentifizierung eines anwenders bei einem zugang zu einem dienst eines diensteanbieters
DE60214632T2 (de) Multidomäne Berechtigung und Authentifizierung
DE602004012996T2 (de) Verfahren und vorrichtung zum authentifizieren von benutzern und websites
DE602004004325T2 (de) Verfahren und Vorrichtung zur Bereitstellung eines sicheren VPN-Zugriffs mittels veränderter Zertifikat-Zeichenketten
DE602004012870T2 (de) Verfahren und system zur benutzerauthentifizierung in einer benutzer-anbieterumgebung
DE60114986T2 (de) Verfahren zur herausgabe einer elektronischen identität
EP2304642B1 (de) Verfahren zum lesen von attributen aus einem id-token
DE112017004033T5 (de) Verfahren zum Erhalten von geprüften Zertifikaten durch Mikrodienste in elastischen Cloud-Umgebungen
DE10392208T5 (de) Mechanismus zum Unterstützten drahtgebundener und drahtloser Verfahren für eine client- und serverseitige Authentifizierung
EP3909221B1 (de) Verfahren zum sicheren bereitstellen einer personalisierten elektronischen identität auf einem endgerät
WO2011131715A1 (de) Verfahren zum lesen eines attributs aus einem id-token
WO2009089943A1 (de) Verfahren zum lesen von attributen aus einem id-token
EP2338255A2 (de) Verfahren, computerprogrammprodukt und system zur authentifizierung eines benutzers eines telekommunikationsnetzwerkes
DE102009001959A1 (de) Verfahren zum Lesen von Attributen aus einem ID-Token über eine Mobilfunkverbindung
WO2015149976A1 (de) Verteiltes authentifizierungssystem und -verfahren
EP3908946B1 (de) Verfahren zum sicheren bereitstellen einer personalisierten elektronischen identität auf einem endgerät
DE60309216T2 (de) Verfahren und vorrichtungen zur bereitstellung eines datenzugriffs
DE10124427A1 (de) System und Verfahren für einen sicheren Vergleich eines gemeinsamen Geheimnisses von Kommunikationsgeräten
EP3685563A1 (de) Verfahren zum einrichten einer benutzer-authentifizierung an einem endgerät mittels eines mobilen endgeräts und zum anmelden eines benutzers an einem endgerät
EP2919145B1 (de) Authentifizierungsvorrichtung, Authentifizierungssystem und Authentifizierungsverfahren
DE102008042582A1 (de) Telekommunikationsverfahren, Computerprogrammprodukt und Computersystem
EP3540623B1 (de) Verfahren zur erzeugung eines pseudonyms mit hilfe eines id-tokens
DE102022000857B3 (de) Verfahren zur sicheren Identifizierung einer Person durch eine Verifikationsinstanz
EP2787709B1 (de) Verfahren zum gewähren eines nutzerzugriffs auf ein kommunikationssystem
EP2397960A1 (de) Verfahren zum Lesen von Attributen aus einem ID-Token über eine Telekommunikations-Chipkarte und ein Server-Computersystem

Legal Events

Date Code Title Description
8364 No opposition during term of opposition