DE102011089580B3

DE102011089580B3 - Verfahren zum Lesen von Attributen aus einem ID-Token

Info

Publication number: DE102011089580B3
Application number: DE201110089580
Authority: DE
Inventors: Carsten Schwarz; Jan Hill; Christian Kahlo
Original assignee: AGETO Innovation GmbH; Bundesdruckerei GmbH
Current assignee: Bundesdruckerei GmbH
Priority date: 2011-12-22
Filing date: 2011-12-22
Publication date: 2013-04-25
Anticipated expiration: 2031-12-23

Abstract

Die Erfindung betrifft ein Datenverarbeitungssystem mit einem ID-Provider-Computersystem (136), wobei das ID-Provider-Computersystem folgendes aufweist: – Mittel (138) zum Empfang eines SAML-Request (190) von einem Anwendungsprogramm (113) eines Nutzer-Computersystems (100) über ein Netzwerk (116), wobei der SAML-Request eine Attributspezifizierung zumindest eines aus einem ID-Token auszulesenden Attributs, eine Adresse und einen Identifikator beinhaltet, – Mittel (142, 144, 146) zur Authentifizierung des ID-Provider-Computersystems gegenüber dem ID-Token über das Netzwerk, – Mittel (148) zur Durchführung eines Lesezugriffs zum Lesen des zumindest einen in dem ID-Token gespeicherten Attributs gemäß der Attributspezifizierung über das Netzwerk nach erfolgreicher Durchführung der Authentifizierung, – Mittel (145, 148) zur Erzeugung einer SAML-Response (192), welche das zumindest eine von dem ID-Provider-Computersystem ausgelesene und signierte Attribut, den Identifikator und eine Adresse beinhaltet, – Mittel (145, 140) zur Speicherung der SAML-Response in einem elektronischen Speicher (140) des ID-Provider-Computersystems, sodass mit Hilfe der Adresse die SAML-Response durch einen Internetbrowser des Nutzer-Computersystems über das Netzwerk abrufbar ist, sodass sie über das Netzwerk von dem ID-Provider-Computersystem an das Nutzer-Computersystem übertragen wird.

Description

Die Erfindung betrifft ein Verfahren zum Lesen von zumindest einem Attribut aus einem ID-Token, ein Computerprogrammprodukt und ein Datenverarbeitungssystem.
Aus dem Stand der Technik sind verschiedene Verfahren zur Verwaltung der so genannten digitalen Identität eines Benutzers bekannt:
Microsoft Windows CardSpace ist ein Client-basiertes digitales Identitätssystem, welches es Internetbenutzern ermöglichen soll, deren digitale Identität gegenüber Online-Diensten mitzuteilen. Nachteilig ist hierbei unter anderem, dass der Nutzer seine digitale Identität manipulieren kann.
Bei OPENID handelt es sich dagegen um ein Server-basiertes System. Ein so genannter Identity-Server speichert eine Datenbank mit den digitalen Identitäten der registrierten Nutzer. Nachteilig ist hieran unter anderem ein mangelhafter Datenschutz, da die digitalen Identitäten der Nutzer zentral gespeichert werden und das Nutzerverhalten aufgezeichnet werden kann.
Aus US 2007/0294431 A1 ist ein weiteres Verfahren zur Verwaltung der digitalen Identitäten bekannt, welches ebenfalls eine Nutzerregistrierung erfordert. Aus der US 2011/0138453 A1 ist gleichfalls ein Verfahren zur Authentifizierung zwischen einem Nutzer-Computersystem, einem Webservice und einem ID-Providercomputersystem bekannt, bei dem jedoch auch eine Nutzerregistrierung erforderlich ist, um durch eine einmalige Anmeldung bei dem ID-Providercomputersystem Zugangsdaten für verschiedene Webservices zur Verfügung stellen zu können.
Aus DE 10 2008 000 067 B4 ist ein Verfahren zum Lesen von Attributen aus einem ID-Token bekannt, bei dem ein ID-Provider-Computersystem über ein Netzwerk zumindest ein Attribut aus dem ID-Token ausliest, wobei es sich bei dem ID-Token zum Beispiel um ein Ausweisdokument handeln kann. Aus DE 10 2008 040 416 A1 , DE 10 2009 001 959 A1 , DE 10 2009 027 676 A1 , DE 10 2009 027 681 A1 , DE 10 2009 027 682 A1 , DE 10 2009 027 686 A1 , DE 10 2009 027 723 A1 , DE 10 2009 046 205 A1 und DE 10 2010 028 133 A1 sind Weiterbildungen und verschiedene Verwendungen dieses Verfahrens bekannt.
Der Erfindung liegt demgegenüber die Aufgabe zugrunde, ein verbessertes Verfahren zum Lesen zumindest eines in einem ID-Token gespeicherten Attributs zu schaffen, sowie ein entsprechendes Computerprogrammprodukt und ein Datenverarbeitungssystem.
Die der Erfindung jeweils zugrunde liegenden Aufgaben werden mit den Merkmalen der unabhängigen Patentansprüche gelöst. Ausführungsformen der Erfindung sind mit den abhängigen Patentansprüchen angegeben.
Nach Ausführungsformen der Erfindung wird ein Verfahren zum Lesen zumindest eines in einem ID-Token gespeicherten Attributs geschaffen. Der ID-Token ist einem Nutzer zugeordnet.
Unter einem „ID-Token” wird hier ein tragbares elektronisches Gerät verstanden, welches zumindest einen Datenspeicher zur Speicherung des zumindest einen Attributs und eine Kommunikations-Schnittstelle zum Auslesen des Attributs aufweist. Vorzugsweise hat der ID-Token einen gesicherten Speicherbereich zur Speicherung des zumindest einen Attributs, um zu verhindern, dass das in dem Speicherbereich gespeicherte Attribut in unerlaubter Weise verändert oder ohne die dafür erforderliche Berechtigung ausgelesen wird.
Insbesondere kann es sich bei dem ID-Token um einen USB-Stick handeln oder ein Dokument, insbesondere ein Wert- oder Sicherheitsdokument. Unter einem „Dokument” werden erfindungsgemäß papierbasierte und/oder kunststoffbasierte Dokumente verstanden, wie zum Beispiel Ausweisdokumente, insbesondere Reisepässe, Personalausweise, Visa sowie Führerscheine, Fahrzeugscheine, Fahrzeugbriefe, Firmenausweise, Gesundheitskarten oder andere ID-Dokumente sowie auch Chipkarten, Zahlungsmittel, insbesondere Banknoten, Bankkarten und Kreditkarten, Frachtbriefe oder sonstige Berechtigungsnachweise, in die ein Datenspeicher zur Speicherung des zumindest einen Attributs integriert ist.
Nach Ausführungsformen der Erfindung ruft der Nutzer, der sich in Besitz des ID-Tokens befindet, mit Hilfe eines Internetbrowsers seines Nutzer-Computersystems eine Internetseite eines Dienst-Computersystems auf, wobei die Internetseite zur Eingabe einer Auswahl eines Dienstes ausgebildet ist.
Unter einem „Nutzer-Computersystem” wird hier ein Computersystem verstanden, auf welches der Nutzer Zugriff hat. Hierbei kann es sich zum Beispiel um einen Personal Computer (PC), ein Tablet PC oder ein Mobilfunkgerät, insbesondere ein Smart Phone, mit einem üblichen Internetbrowser, wie zum Beispiel Microsoft Internet Explorer, Safari, Google Chrome, Firefox handeln. Das Nutzer-Computersystem hat eine Schnittstelle zur Verbindung mit dem Netzwerk, wobei es sich bei dem Netzwerk um ein privates oder öffentliches Netzwerk handeln kann, insbesondere das Internet.
Unter einem „Dienst-Computersystem” wird hier ein Computersystem verstanden, welches über eine Netzwerk-Schnittstelle zur Verbindung mit dem Netzwerk verfügt, sodass mit Hilfe des Internetbrowsers des Nutzer-Computersystems und anderer Nutzer-Computersysteme auf von dem Dienst-Computersystem gespeicherte oder generierte Internetseiten zugegriffen werden kann. Insbesondere kann es sich bei dem Dienst-Computersystem um einen Internetserver zur Verfügungstellung eines Online-Dienstes handeln, insbesondere um eine sogenannte eCommerce-Plattform.
Bei den angebotenen Diensten kann es sich um verschiedene Dienstleistungen oder Produkte handeln, wie zum Beispiel die Eröffnung eines Bankkontos, das Herunterladen oder Streaming von Daten oder die Bestellung eines Produkts. Insbesondere kann das Dienst-Computersystem auch zur Erbringung von behördlichen Diensten oder zur Erfüllung hoheitlicher Aufgaben ausgebildet sein, insbesondere für sogenannte eGovernment-Anwendungen.
Mit Hilfe des Internetbrowsers kann der Nutzer eine Internetseite des Dienst-Computersystems auswählen und auf das Nutzer-Computersystem laden. Der Nutzer kann daraufhin mit Hilfe des Internetbrowsers einen auf der Internetseite angebotenen Dienst auswählen und die entsprechende Auswahlentscheidung über den Internetbrowser eingeben, sodass diese Eingabe an das Dienst-Computersystem übertragen wird. Insbesondere erfolgt dies im Rahmen einer sogenannten Session, die zwischen dem Dienst-Computersystem und dem Internetbrowser für den Zugriff auf die Internetseite aufgebaut wird.
Für die Auswahl des Dienstes, welche das Dienst-Computersystem von dem Nutzer empfangen hat, vergibt dieses einen Identifikator, welchen das Dienst-Computersystem zumindest temporär speichert. Der Identifikator wird der empfangenen Auswahl des Dienstes zugeordnet und diese Zuordnung wird von dem Dienst-Computersystem gespeichert. Insbesondere kann ein Identifikator der zwischen dem Dienst-Computersystem und dem Nutzer-Computersystem aufgebauten Session, das heißt die sogenannte Session-ID, als Identifikator dienen. Alternativ kann der Identifikator dem Nutzer fest zugeordnet und im Voraus vergeben sein.
Von dem Dienst-Computersystem wird dann zumindest ein Parameter zum Aufruf eines Anwendungsprogramms des Nutzer-Computersystems zusammen mit einer Adresse und dem Identifikator an den Internetbrowser des Nutzer-Computersystems übertragen. Das Anwendungsprogramm des Nutzer-Computersystems wird dann durch den Internetbrowser aufgerufen, und zwar mit Hilfe des zumindest einen Parameters. Der Internetbrowser gibt die von dem Dienst-Computersystem empfangene Adresse und den Identifikator in das Anwendungsprogramm ein.
Das Anwendungsprogramm überträgt daraufhin eine Anforderung an das Dienst-Computersystem, wobei die Anforderung die Adresse und den Identifikator beinhaltet. Als Reaktion auf diese Anforderung erzeugt dann das Dienst-Computersystem einen SAML-Request. Das Dienst-Computersystem fungiert dabei also als SAML-Requester (vgl. Security Assertion Markup Language (SAML) V2.0 Technical Overview, OASIS, Committee Draft 02, 25. März 2008).
Der SAML-Request beinhaltet eine Attributspezifizierung zur Spezifizierung des zumindest einen aus dem ID-Token auszulesenden Attributs. Insbesondere kann die Attributspezifizierung durch Angabe einer Bezeichnung des zu lesenden Attributs erfolgen, wie zum Beispiel „Name”, „Alter”, „Guthaben”, um zum Beispiel den Namen, das Alter bzw. ein Guthaben des Nutzers aus dem ID-Token auszulesen.
Der SAML-Request wird von dem Dienst-Computersystem über das Netzwerk an das Anwendungsprogramm gesendet, welches den SAML-Request dann an ein ID-Provider-Computersystem über das Netzwerk weiterleitet.
Unter einem „ID-Provider-Computersystem” wird hier ein Computersystem verstanden, welches dazu ausgebildet ist, das zumindest eine Attribut aus dem ID-Token auszulesen, beispielsweise zur Erbringung eines Dienstes für die Ermittlung der digitalen Identität des Nutzers oder des ID-Tokens selbst. Die digitale Identität wird hierbei durch das zumindest eine auszulesende Attribut bestimmt.
Aufgrund des SAML-Request führt das ID-Provider-Computersystem einen Lesezugriff auf den ID-Token durch, um die gemäß der Attributspezifizierung erforderlichen ein oder mehreren Attribute aus dem ID-Token auszulesen. Hierzu ist es zunächst erforderlich, dass sich sowohl das ID-Provider-Computersystem als auch der Nutzer gegenüber dem ID-Token authentifizieren, wie es an sich aus DE 10 2008 000 067 B4 bekannt ist.
Das ID-Provider-Computersystem erzeugt dann eine SAML-Response, fungiert also als SAML-Responder. Die SAML-Response beinhaltet das zumindest eine aus dem ID-Token ausgelesene Attribut und ist signiert, sodass die SAML-Response über das Netzwerk übertragen werden kann, ohne dass ein Dritter die SAML-Response unentdeckt manipulieren könnte. Vorzugsweise beinhaltet die SAML-Response auch den Identifikator, welchen das ID-Provider-Computersystem mit dem SAML-Request erhalten hat.
Das ID-Provider-Computersystem speichert die erzeugte SAML-Response, sodass sie von dem ID-Provider-Computersystem mit Hilfe der Adresse abgerufen werden kann. Durch die Adresse wird also ein Zugriffsschlüssel zum Abruf der SAML-Response von dem ID-Provider-Computersystem über das Netzwerk gebildet.
Die Speicherung der SAML-Response und deren Verfügbarkeit zum Abrufen wird von dem ID-Provider-Computersystem an das Anwendungsprogramm über das Netzwerk signalisiert und das Anwendungsprogramm antwortet daraufhin auf den Aufruf des Internetbrowsers, indem das Anwendungsprogramm den Internetbrowser die Speicherung der SAML-Response signalisiert.
Der Internetbrowser ruft dann die SAML-Response über das Netzwerk mit Hilfe der Adresse ab, sodass die SAML-Response von dem ID-Provider-Computersystem zu dem Internetbrowser übertragen wird. Der Internetbrowser leitet dann die SAML-Response an das Dienst-Computersystem weiter.
Das Dienst-Computersystem ordnet die SAML-Response mit Hilfe des in der SAML-Response beinhalteten Identifikators der zuvor GETroffenen Auswahl des Dienstes zu. Dies ist besonders vorteilhaft, weil auf diese Art und Weise Auswahlen von Diensten des Dienst-Computersystems verschiedener Nutzer gleichzeitig verarbeitet werden können, weil aufgrund des Identifikators jeweils eine Zuordnung zwischen SAML-Request, SAML-Response und der eingegebenen Auswahl des Dienstes bzw. der Internetsession gegeben ist.
Das Dienst-Computersystem kann dann anhand der SAML-Response, welche das zumindest eine Attribut beinhaltet, prüfen, ob ein vorgegebenes Kriterium für die Erbringung des ausgewählten Dienstes für den Nutzer erfüllt ist, beispielsweise ob der durch seinen Namen ausgewiesene Nutzer zu einer autorisierten Nutzergruppe gehört, ob der Nutzer zum Beispiel volljährig ist, oder ob der Nutzer über ein ausreichendes Guthaben verfügt. Wenn das entsprechende Kriterium erfüllt ist, kann dann das Dienst-Computersystem den ausgewählten Dienst erbringen.
Nach einer Ausführungsform der Erfindung handelt es sich bei den Parametern zum Aufruf des Anwendungsprogramms um eine Transmission Control Protocol(TCP)-Portnummer und eine Internetprotokoll(IP)-Adresse des Anwendungsprogramms handelt, wobei das Anwendungsprogramm durch Senden der Adresse und des Identifikators an die Portnummer und Adressierung mit der IP-Adresse aufgerufen wird.
Das Anwendungsprogramm kann beispielsweise permanent ausgeführt werden, um auf seinen Aufruf über eine bestimmte Portnummer zu warten. Erfolgt der Aufruf mit der IP-Adresse des Anwendungsprogramms, werden durch den Aufruf die Adresse und der Identifikator in das Anwendungsprogramm eingegeben, welches daraufhin eine Anforderung an das Dienst-Computersystem richtet, um damit zu signalisieren, dass die Erzeugung eines SAML-Requests erforderlich ist.
Nach einer Ausführungsform der Erfindung haben sowohl das Anwendungsprogramm als auch das ID-Provider-Computersystem jeweils ein Application Programming Interface (API) welche zur Signalisierung der Speicherung der SAML-Response dienen. Beispielsweise können die APIs nach dem eCard-API-Framework ausgebildet sein, wie es vom Bundesamt für die Sicherheit in der Informationstechnik spezifiziert ist, nämlich in BSI TR-03112, insbesondere Teil 2.
Ausführungsformen der Erfindung sind besonders vorteilhaft, da kein Browser-Plugin erforderlich ist, sodass die Erfindung unabhängig von dem verwendeten Internetbrowser und dessen Programmversion implementiert werden kann. Auf dem Nutzer-Computersystem muss also lediglich das Anwendungsprogramm installiert werden. Dies ist besonders vorteilhaft, wenn das Nutzer-Computersystem einen Internetbrowser hat, welcher keine Plugins zulässt, was insbesondere dann der Fall sein kann, wenn es sich bei dem Nutzer-Computersystem um ein Smartphone oder einen Tablet-PC handelt.
Nach Ausführungsformen der Erfindung erfolgt der Aufruf des Anwendungsprogramms durch ein HTTP GET-Kommando, welches die Adresse und den Identifikator beinhaltet.
Nach einer Ausführungsform der Erfindung antwortet das Anwendungsprogramm auf den Aufruf mit dem HTTP GET-Kommando durch den HTTP Statuscode 303, so wie in RFC 2616, sowie RFC 2518, RFC 2817, RFC 2295, RFC 2774 und RFC 4918 spezifiziert. Im dem Location Header Feld des HTTP Statuscode 303 ist dabei die Adresse angegeben, mit Hilfe derer die SAML-Response von dem ID-Provider-Computersystem abrufbar ist. Mit Hilfe eines HTTP GET-Kommandos und der Adresse kann der Internetbrowser dann die SAML-Response abrufen.
Nach einer Ausführungsform der Erfindung sendet das Anwendungsprogramm in dem Zeitraum zwischen dem Empfang des Aufrufs von dem Internetbrowser und der Antwort auf den Aufruf ein oder mehrfach ein Signal an den Internetbrowser, um einen Timeout des Internetbrowsers aufgrund der ausbleibenden Antwort zu verhindern. Je nach Ausführungsform kann die Zeitdauer zwischen dem Aufruf des Anwendungsprogramms, zum Beispiel mittels des HTTP GET-Kommandos, und der Antwort hierauf, das heißt beispielsweise dem HTTP Statuscode 303, beispielsweise mehrere Sekunden bis zu einer Minute betragen, was je nach Konfiguration des Internetbrowsers zu einem Timeout und damit zu einer Fehlermeldung führen kann. Um dies zu vermeiden, sendet das Anwendungsprogramm zur Überbrückung dieses Zeitraums ein oder mehrfach ein Signal an den Internetbrowser, nämlich beispielsweise einen HTTP 102 Statuscode.
In einem weiteren Aspekt betrifft die Erfindung ein Computerprogrammprodukt, insbesondere ein digitales Speichermedium, mit ausführbaren Instruktionen zur Durchführung eines Verfahrens nach einem der vorhergehenden Ansprüche.
In einem weiteren Aspekt betrifft die Erfindung ein Datenverarbeitungssystem mit einem ID-Provider-Computersystem. Das ID-Provider-Computersystem beinhaltet Mittel zum Empfang eines SAML-Request von einem Anwendungsprogramm eines Nutzer-Computersystems über ein Netzwerk, wobei der SAML-Request eine Attributspezifizierung zumindest eines aus einem ID-Token auszulesenden Attributs, eine Adresse und einen Identifikator beinhaltet, Mittel zur Authentifizierung des ID-Provider-Computersystems gegenüber dem ID-Token über das Netzwerk, Mittel zur Durchführung eines Lesezugriffs zum Lesen des zumindest einen in dem ID-Token gespeicherten Attributs gemäß der Attributspezifizierung über das Netzwerk nach erfolgreicher Durchführung der Authentifizierung, Mittel zur Erzeugung einer SAML-Response, welche das zumindest eine von dem ID-Provider-Computersystem ausgelesene und signierte Attribut, den Identifikator und eine Adresse beinhaltet, und Mittel zur Speicherung der SAML-Response in einem elektronischen Speicher des ID-Provider-Computersystems, sodass mit Hilfe der Adresse die SAML-Response durch einen Internetbrowser des Nutzer-Computersystems über das Netzwerk abrufbar ist, sodass sie über das Netzwerk von dem ID-Provider-Computersystem an das Nutzer-Computersystem übertragen wird.
Das Datenverarbeitungssystem kann ferner ein oder mehrere der Nutzer-Computersysteme und ID-Token sowie zumindest ein Dienst-Computersystem beinhalten.
Im Weiteren werden Ausführungsformen der Erfindung mit Bezugnahme auf die Zeichnungen näher erläutert. Es zeigen:
1 ein Blockdiagramm einer ersten Ausführungsform eines erfindungsgemäßen Datenverarbeitungssystems,
2 ein Flussdiagramm einer Ausführungsform eines erfindungsgemäßen Verfahrens,
3 ein UML-Diagramm einer weiteren Ausführungsform eines erfindungsgemäßen Verfahrens.
Elemente der nachfolgenden Ausführungsformen, die einander entsprechen oder gleichen, werden mit denselben Bezugszeichen gekennzeichnet.
Die 1 zeigt ein Nutzer-Computersystem 100 eines Nutzers 102. Bei dem Nutzer-Computersystem 100 kann es sich um einen Personalcomputer, einen tragbaren Computer, wie zum Beispiel einen Laptop oder Palmtop-Computer, einen Personal Digital Assistant, einen Tablet-PC, ein mobiles Telekommunikationsgerät, insbesondere ein Smart Phone, oder dergleichen handeln. Das Nutzer-Computersystem 100 hat eine Schnittstelle 104 zur Kommunikation mit einem ID-Token 106, der eine entsprechende Schnittstelle 108 aufweist.
Das Nutzer-Computersystem 100 hat zumindest einen Prozessor 110 zur Ausführung von Programminstruktionen, nämlich zumindest einem Internetbrowser 112 und einem Anwendungsprogramm 113, sowie eine Netzwerk-Schnittstelle 114 zur Kommunikation über ein Netzwerk 116. Bei dem Netzwerk kann es sich um ein Computernetzwerk, wie zum Beispiel das Internet, handeln.
Der ID-Token 106 hat einen elektronischen Speicher 118 mit geschützten Speicherbereichen 120, 122 und 124. Der geschützte Speicherbereich 120 dient zur Speicherung eines Referenzwerts, der für die Authentifizierung des Nutzers 102 gegenüber dem ID-Token 106 benötigt wird. Bei diesem Referenzwert handelt es sich beispielsweise um eine Kennung, insbesondere eine so genannte Personal Identification Number (PIN), oder um Referenzdaten für ein biometrisches Merkmal des Nutzers 102, welches für die Authentifizierung des Nutzers gegenüber dem ID-Token 106 verwendet werden kann.
Der geschützte Bereich 122 dient zur Speicherung eines privaten Schlüssels und der geschützte Speicherbereich 124 dient zur Speicherung von Attributen, zum Beispiel des Nutzers 102, wie zum Beispiel dessen Name, Wohnort, Geburtsdatum, Geschlecht, und/oder von Attributen, die den ID-Token selbst betreffen, wie zum Beispiel die Institution, die den ID-Token erstellt oder ausgegeben hat, die Gültigkeitsdauer des ID-Tokens, einen Identifikator des ID-Tokens, wie zum Beispiel eine Passnummer oder eine Kreditkartennummer.
Der elektronische Speicher 118 kann ferner einen Speicherbereich 126 zur Speicherung eines Zertifikats aufweisen. Das Zertifikat beinhaltet einen öffentlichen Schlüssel, der dem in dem geschützten Speicherbereich 122 gespeicherten privaten Schlüssel zugeordnet ist. Das Zertifikat kann nach einem Public Key Infrastruktur (PKI) Standard erstellt worden sein, belspielsweise nach dem X.509 Standard.
Das Zertifikat muss nicht zwangsläufig in dem elektronischen Speicher 118 des ID-Tokens 106 gespeichert sein. Alternativ oder zusätzlich kann das Zertifikat auch in einem öffentlichen Verzeichnisserver gespeichert sein.
Der ID-Token 106 hat einen Prozessor 128. Der Prozessor 128 dient zur Ausführung von Programminstruktionen 130, 132 und 134. Die Programminstruktionen 130 dienen zur Nutzerauthentifizierung, d. h. zur Authentifizierung des Nutzers 102 gegenüber dem ID-Token.
Bei einer Ausführungsform mit PIN gibt der Nutzer 102 seine PIN zu seiner Authentifizierung in den ID-Token 106 ein, beispielsweise über das Nutzer-Computersystem 100. Durch Ausführung der Programminstruktionen 130 wird dann auf den geschützten Speicherbereich 120 zugegriffen, um die eingegebene PIN mit dem dort gespeicherten Referenzwert der PIN zu vergleichen. Für den Fall, dass die eingegebene PIN mit dem Referenzwert der PIN übereinstimmt, gilt der Nutzer 102 als authentifiziert.
Alternativ wird ein biometrisches Merkmal des Nutzers 102 erfasst. Beispielsweise hat der ID-Token 106 hierzu einen Fingerabdrucksensor oder ein Fingerabdrucksensor ist an das Nutzer-Computersystem 100 angeschlossen. Die von dem Nutzer 102 erfassten biometrischen Daten werden durch Ausführung der Programminstruktionen 130 bei dieser Ausführungsform mit den in dem geschützten Speicherbereich 120 gespeicherten biometrischen Referenzdaten verglichen. Bei hinreichender Übereinstimmung der von dem Nutzer 102 erfassten biometrischen Daten mit den biometrischen Referenzdaten gilt der Nutzer 102 als authentifiziert.
Die Programminstruktionen 134 dienen zur Ausführung der den ID-Token 106 betreffenden Schritte eines kryptographischen Protokolls zur Authentifizierung eines ID-Provider-Computersystems 136 gegenüber dem ID-Token 106. Bei dem kryptographischen Protokoll kann es sich um ein Challenge-Response-Protokoll basierend auf einem symmetrischen Schlüssel oder einem asymmetrischen Schlüsselpaar handeln.
Beispielsweise wird durch das kryptographische Protokoll ein Extended Access Control-Verfahren implementiert, wie es für maschinenlesbare Reisedokumente (machine-readable travel documents – MRTD) von der internationalen Luftfahrtbehörde (ICAO) spezifiziert ist. Durch erfolgreiche Ausführung des kryptographischen Protokolls authentifiziert sich das ID-Provider-Computersystem 136 gegenüber dem ID-Token und weist dadurch seine Leseberechtigung zum Lesen der in dem geschützten Speicherbereich 124 gespeicherten Attribute nach. Die Authentifizierung kann auch gegenseitig sein, d. h. auch der ID-Token 106 muss sich dann gegenüber dem ID-Provider-Computersystem 136 nach demselben oder einem anderen kryptographischen Protokoll authentifizieren.
Die Programminstruktionen 132 dienen zur Ende-zu-Ende-Verschlüsselung von zwischen dem ID-Token 106 und dem ID-Provider-Computersystem 136 übertragenen Daten, zumindest aber der von dem ID-Provider-Computersystem 136 aus dem geschützten Speicherbereich 124 ausgelesenen Attribute. Für die Ende-zu-Ende-Verschlüsselung kann ein symmetrischer Schlüssel verwendet werden, der beispielsweise anlässlich der Ausführung des kryptographischen Protokolls zwischen dem ID-Token 106 und dem ID-Provider-Computersystem 136 vereinbart wird.
Alternativ zu der in der 1 dargestellten Ausführungsform kann das Nutzer-Computersystem 100 mit seiner Schnittstelle 104 nicht unmittelbar mit der Schnittstelle 108 kommunizieren, sondern über ein an die Schnittstelle 104 angeschlossenes Lesegerät für den ID-Token 106. Über dieses Lesegerät, wie zum Beispiel einen so genannten Klasse 2-Chipkarten-Terminal, kann auch die Eingabe der PIN erfolgen.
Das ID-Provider-Computersystem 136 hat eine Netzwerk-Schnittstelle 138 zur Kommunikation über das Netzwerk 116. Das ID-Provider-Computersystem 136 hat ferner einen Speicher 140, in dem ein privater Schlüssel 142 des ID-Provider-Computersystems 136 sowie das entsprechende Zertifikat 144 gespeichert ist. Auch bei diesem Zertifikat kann es sich beispielsweise um ein Zertifikat nach einem PKI-Standard, wie zum Beispiel X.509 handeln.
Das ID-Provider-Computersystem 136 hat ferner zumindest einen Prozessor 145 zur Ausführung von Programminstruktionen 146 und 148. Durch Ausführung der Programminstruktionen 146 werden die das ID-Provider-Computersystem 136 betreffende Schritte des kryptographischen Protokolls ausgeführt. Insgesamt wird also das kryptographische Protokoll durch Ausführung der Programminstruktionen 134 durch den Prozessor 128 des ID-Tokens 106 sowie durch Ausführung der Programminstruktionen 146 durch den Prozessor 145 des ID-Provider-Computersystems 136 implementiert.
Die Programminstruktionen 148 dienen zur Implementierung der Ende-zu-Ende-Verschlüsselung auf Seiten des ID-Provider-Computersystems 136, beispielsweise basierend auf dem symmetrischen Schlüssel, der anlässlich der Ausführung des kryptographischen Protokolls zwischen dem ID-Token 106 und dem ID-Provider-Computersystem 136 vereinbart worden ist. Prinzipiell kann jedes an sich vor bekannte Verfahren zur Vereinbarung des symmetrischen Schlüssels für die Ende-zu-Ende-Verschlüsselung verwendet werden, wie zum Beispiel ein Diffie-Hellman-Schlüsselaustausch.
Das ID-Provider-Computersystem 136 befindet sich vorzugsweise in einer besonders geschützten Umgebung, insbesondere in einem so genannten Trust-Center, sodass das ID-Provider-Computersystem 136 in Kombination mit der Notwendigkeit der Authentifizierung des Nutzers 102 gegenüber dem ID-Token 106 den Vertrauensanker für die Authentizität der aus dem ID-Token 106 ausgelesenen Attribute bildet.
Ein Dienst-Computersystem 150 kann zur Entgegennahme einer Bestellung oder eines Auftrags für eine Dienstleistung oder ein Produkt, insbesondere eine Online-Dienstleistung, ausgebildet sein. Beispielsweise kann der Nutzer 102 online über das Netzwerk 116 ein Konto bei einer Bank eröffnen oder eine andere Finanz- oder Bankdienstleistung in Anspruch nehmen. Das Dienst-Computersystem 150 kann auch als Online-Warenhaus ausgebildet sein, sodass der Benutzer 102 beispielsweise online ein Mobiltelefon oder dergleichen erwerben kann. Ferner kann das Dienst-Computersystem 150 auch zur Lieferung von digitalen Inhalten ausgebildet sein, beispielsweise für den Download von Musik- und/oder Videodaten.
Das Dienst-Computersystem 150 hat hierzu eine Netzwerk-Schnittstelle 152 zur Verbindung mit dem Netzwerk 116. Ferner hat das Dienst-Computersystem 150 zumindest einen Prozessor 154 zur Ausführung von Programminstruktionen 156. Durch Ausführung der Programminstruktionen 156 werden beispielsweise dynamische HTML-Seiten generiert, über die der Nutzer 102 seinen Auftrag oder seine Bestellung eingeben kann.
Je nach der Art des beauftragten oder bestellten Produkts oder der Dienstleistung muss das Dienst-Computersystem 150 ein oder mehrere Attribute des Nutzers 102 und/oder dessen ID-Token 106 anhand eines oder mehrerer vorgegebener Kriterien überprüfen. Nur wenn diese Prüfung bestanden wird, wird die Bestellung oder der Auftrag des Nutzers 102 entgegengenommen und/oder ausgeführt.
Beispielsweise ist es für die Eröffnung eines Bankkontos oder den Kauf eines Mobiltelefons mit einem dazugehörigen Vertrag erforderlich, dass der Nutzer 102 seine Identität gegenüber dem Dienst-Computersystem 150 offenbart, und dass diese Identität überprüft wird. Im Stand der Technik muss der Nutzer 102 hierzu beispielsweise seinen Personalausweis vorlegen. Dieser Vorgang wird durch das Auslesen der digitalen Identität des Nutzers 102 aus seinem ID-Token 106 ersetzt.
Je nach Anwendungsfall muss der Nutzer 102 aber nicht seine Identität gegenüber dem Dienst-Computersystem 150 offenbaren, sondern es reicht die Mitteilung, zum Beispiel nur eines der Attribute aus. Beispielsweise kann der Nutzer 102 über eines der Attribute einen Nachweis erbringen, dass er zu einer bestimmten Personengruppe gehört, die zugangsberechtigt für auf dem Dienst-Computersystem 150 zum Download bereitgehaltener Daten ist. Beispielsweise kann ein solches Kriterium ein Mindestalter des Nutzers 102 sein oder die Zugehörigkeit des Nutzers 102 zu einem Personenkreis, der auf bestimmte vertrauliche Daten eine Zugriffsberechtigung hat.
Nach Ausführungsformen der Erfindung haben das Anwendungsprogramm 113 und die Programminstruktionen 148 eine API, insbesondere entsprechend dem eCard-API-Framework.
Zur Inanspruchnahme des von dem Dienst-Computersystem 150 zur Verfügung gestellten Dienstes wird wie folgt vorgegangen:
Der Nutzer 102 startet den Internetbrowser 112 und gibt die URL einer Internetseite ein, um die entsprechende Internetseite von dem Dienst-Computersystem 150 auf das Nutzer-Computersystem 100 zu laden und dort anzuzeigen. Der Nutzer 102 wählt dann auf der Internetseite einen bestimmten Dienst aus, in dem er beispielsweise in einem Online-Katalog ein bestimmtes Produkt auswählt, oder zum Beispiel bei einer eGovernment-Anwendung eine bestimmte behördliche Dienstleistung auswählt.
Seine auf der Internetseite GETätigte Eingabe bestätigt der Nutzer 102 beispielsweise durch Betätigung der Entertaste auf der Tastatur des Nutzer-Computersystems oder durch einen Mausklick mit der Computermaus des Nutzer-Computersystems, sodass die Auswahl dieses Dienstes von dem Internetbrowser 112 an das Dienst-Computersystem 150 übertragen wird, zum Beispiel im Rahmen einer sogenannten Session, welche initial zwischen dem Internetbrowser 112 und dem Dienst-Computersystem 150 aufgebaut wird.
Für eine solche Session wird ein Identifikator vergeben, das heißt eine sogenannte Session-ID 174. Über die Session-ID 174 ist somit eine Zuordnung der von dem Dienst-Computersystem empfangenen Auswahl eines Dienstes und dem Internetbrowser 112 des Nutzer-Computersystems 100, von dem diese Eingabe empfangen worden ist, gegeben. Eine solche Session-ID 174 kann beispielsweise in einem Speicher 172 des Dienst-Computersystems 150 zumindest temporär gespeichert werden.
In dem Speicher 172 können ferner Parameter 176 und eine Adresse 178 gespeichert sein.
Als Antwort auf den Empfang der Auswahl des Dienstes von dem Internetbrowser 112 überträgt das Dienst-Computersystem 150 die Parameter 176, die Adresse 178 sowie den Identifikator, das heißt hier die Session-ID 174 an den Internetbrowser 112, beispielsweise durch eine HTTP-Response 182 auf einen HTTP-Request des Internetbrowsers 112, wie zum Beispiel auf HTTP GET 180, womit die Eingabe des Nutzers 102 für die Auswahl des Dienstes an das Dienst-Computersystem 150 von dem Internetbrowser 112 kommuniziert wird.
Der Internetbrowser 112 ruft aufgrund der HTTP-Response 182 das Anwendungsprogramm 113 auf, beispielsweise indem er ein HTTP GET 184 an das Anwendungsprogramm 113 innerhalb des Nutzer-Computersystems 100 richtet.
Beispielsweise beinhalten die Parameter 176 eine TCP-Portnummer und eine IP-Adresse des Anwendungsprogramms 113. Das Anwendungsprogramm 113 wird ständig im Hintergrund ausgeführt und wartet auf den Empfang von HTTP GET 184 an der TCP-Portnummer, welche an seine IP-Adresse gerichtet ist. Über HTTP GET 184 wird also das Anwendungsprogramm 113 von dem Internetbrowser 112 aufgerufen und es werden ferner die Adresse 178 und die Session-ID 174 in das Anwendungsprogramm 113 eingegeben.
Das Anwendungsprogramm 113 reagiert auf HTTP GET 184 mit einer Anforderung, wie zum Beispiel HTTP GET 186, welche das Anwendungsprogramm 113 über die Netzwerk-Schnittstelle 114 an das Dienst-Computersystem 150 sendet. HTTP GET 184 beinhaltet dabei wiederum die Session-ID 174 und die Adresse 178.
Als Reaktion auf HTTP GET 186 wird durch Ausführung der Programminstruktionen 156 ein SAML-Request von dem Dienst-Computersystem 150 erzeugt. Der SAML-Request beinhaltet eine Attributspezifizierung zur Spezifizierung von zumindest eines der in dem Speicher 118 gespeicherten Attribute, welche das Dienst-Computersystem 150 als Voraussetzung für die Erbringung des ausgewählten Dienstes überprüfen muss. Beispielsweise kann in dem Speicher 172 eine Zuordnungstabelle 188 gespeichert sein, in der jedem auf der Internetseite angebotenen Dienst eine entsprechende Attributspezifizierung zugeordnet ist.
Das Dienst-Computersystem 150 greift also auf die Zuordnungstabelle 188 zu, um in Abhängigkeit von dem zuvor ausgewählten Dienst die entsprechende Attributspezifizierung zu bestimmen. Diese Attributspezifizierung wird in dem SAML-Request gespeichert, welcher ferner auch die Session-ID 174 beinhaltet. Dieser SAML-Request 190 wird dann von dem Dienst-Computersystem 150 an das Anwendungsprogramm 113 übertragen.
Das Anwendungsprogramm 113 leitet den SAML-Request dann an das ID-Provider-Computersystem 136 weiter. Das ID-Provider-Computersystem 136 liest daraufhin die durch die Attributspezifizierung des SAML-Request festgelegten Attribute aus dem ID-Token 106 aus, indem die folgenden Schritte durchgeführt werden:

1. Authentifizierung des Nutzers 102 gegenüber dem ID-Token 106.

Der Nutzer 102 authentifiziert sich gegenüber dem ID-Token 106. Bei einer Implementierung mit PIN gibt der Nutzer 102 hierzu seine PIN beispielsweise über das Nutzer-Computersystem 100 oder einen daran angeschlossenen Chipkarten-Terminal ein. Durch Ausführung der Programminstruktionen 130 prüft dann der ID-Token 106 die Korrektheit der eingegebenen PIN. Wenn die eingegebene PIN mit dem in dem geschützten Speicherbereich 120 gespeicherten Referenzwert der PIN übereinstimmt, so gilt der Nutzer 102 als authentifiziert. Analog kann vorgegangen werden, wenn ein biometrisches Merkmal des Nutzers 102 zu dessen Authentifizierung verwendet wird, wie oben beschrieben.

2. Authentifizierung des ID-Provider-Computersystems 136 gegenüber dem ID-Token 106.

Hierzu wird eine Verbindung zwischen dem ID-Token 106 und dem ID-Provider-Computersystem 136 über das Nutzer-Computersystem 100 und das Netzwerk 116 hergestellt. Beispielsweise überträgt das ID-Provider-Computersystem 136 sein Zertifikat 144 über diese Verbindung an den ID-Token 106. Durch die Programminstruktionen 134 wird dann eine so genannte Challenge generiert, d. h. beispielsweise eine Zufallszahl. Diese Zufallszahl wird mit dem in dem Zertifikat 144 beinhalteten öffentlichen Schlüssel des ID-Provider-Computersystems 136 verschlüsselt. Das resultierende Chiffrat wird von dem ID-Token 106 über die Verbindung an das ID-Provider-Computersystem 136 gesendet. Das ID-Provider-Computersystem 136 entschlüsselt das Chiffrat mit Hilfe seines privaten Schlüssels 142 und erhält so die Zufallszahl. Die Zufallszahl sendet das ID-Provider-Computersystem 136 über die Verbindung an den ID-Token 106 zurück. Durch Ausführung der Programminstruktionen 134 wird dort geprüft, ob die von dem ID-Provider-Coinputersystem 136 empfangene Zufallszahl mit der ursprünglich generierten Zufallszahl, d. h. der Challenge, übereinstimmt. Ist dies der Fall, so gilt das ID-Provider-Computersystem 136 als gegenüber dem ID-Token 106 authentifiziert. Die Zufallszahl kann als symmetrischer Schlüssel für die Ende-zu-Ende Verschlüsselung verwendet werden.

3. Nachdem sich der Nutzer 102 erfolgreich gegenüber dem ID-Token 106 authentifiziert hat, und nachdem sich das ID-Provider-Computersystem 136 erfolgreich gegenüber dem ID-Token 106 authentifiziert hat, erhält das ID-Provider-Computersystem 136 eine Leseberechtigung zum Auslesen, eines, mehrerer oder aller der in dem geschützten Speicherbereich 124 gespeicherten Attribute. Aufgrund eines entsprechenden Lesekommandos, welches das ID-Provider-Computersystem 136 über die Verbindung an den ID-Token 106 sendet, werden die angeforderten Attribute aus dem geschützten Speicherbereich 124 ausgelesen und durch Ausführung der Programminstruktionen 132 verschlüsselt. Die verschlüsselten Attribute werden über die Verbindung an das ID-Provider-Computersystem 136 übertragen und dort durch Ausführung der Programminstruktionen 148 entschlüsselt. Dadurch erhält das ID-Provider-Computersystem 136 Kenntnis der aus dem ID-Token 106 ausgelesenen Attribute.

Mit den auf diese Art und Weise ausgelesenen Attributen erzeugt das ID-Provider-Computersystem 136 dann eine SAML-Response 192, wobei die Attribute durch das ID-Provider-Computersystem 136 signiert werden.
Die SAML-Response wird dann durch das ID-Provider-Computersystem 136 zum Beispiel in dessen Speicher 140 gespeichert, und zwar so, dass die SAML-Response 192 aus dem Speicher 140 mit Hilfe der Adresse 178 abrufbar ist.
Die Verfügbarkeit der SAML-Response 192 in dem Speicher 140 wird von dem ID-Provider-Computersystem 136 durch Sendung eines Signals 194 signalisiert, beispielsweise indem durch die Programminstruktionen 148 ein solches Signal 194 generiert und an das Anwendungsprogramm 113 gesendet wird. Das Anwendungsprogramm 113 antwortet auf dieses Signal 194, indem es die Verfügbarkeit der SAML-Response 192 in dem Speicher 140 an den Internetbrowser signalisiert, beispielsweise durch einen HTTP Statuscode 303, dessen Location Header Feld die Adresse 178 beinhaltet. Der Internetbrowser 112 ruft daraufhin die SAML-Response 192 mit Hilfe der Adresse 178 von dem ID-Provider-Computersystem 136 ab, sodass die SAML-Response 192 von dem ID-Provider-Computersystem 136 an den Internetbrowser 112 und das Netzwerk 116 übertragen wird.
Die SAML-Response 192 wird von dem Internetbrowser 112 an das Dienst-Computersystem 150 über das Netzwerk 116 weitergeleitet. Das Dienst-Computersystem 150 ordnet dann durch Ausführung der Programminstruktionen 156 die SAML-Response 192 der zwischen dem Internetbrowser 112 und dem Dienst-Computersystem 150 anhängigen Session zu, und zwar mit Hilfe der Session-ID 174, die in der SAML-Response 192 beinhaltet ist.
Dadurch wird das Dienst-Computersystem 150 über die aus dem ID-Token 106 ausgelesenen Attribute in Kenntnis gesetzt, sodass das Dienst-Computersystem 150 diese Attribute anhand der vorgegebenen ein oder mehreren Kriterien prüfen kann, um danach ggf. den von dem Benutzer 102 angeforderten Dienst zu erbringen.
Durch die Notwendigkeit der Authentifizierung des Nutzers 102 gegenüber dem ID-Token 106 und der Authentifizierung des ID-Provider-Computersystems 136 gegenüber dem ID-Token 106 ist der notwendige Vertrauensanker geschaffen, sodass das Dienst-Computersystem 150 sicher sein kann, dass die ihm von dem ID-Provider-Computersystem 136 mitgeteilten Attribute des Nutzers 102 zutreffend und nicht verfälscht sind.
Je nach Ausführungsform kann die Reihenfolge der Authentifizierung unterschiedlich sein. Beispielsweise kann vorgesehen sein, dass sich zunächst der Nutzer 102 gegenüber dem ID-Token 106 authentifizieren muss und nachfolgend das ID-Provider-Computersystem 136. Es ist aber grundsätzlich auch möglich, dass sich zunächst das ID-Provider-Computersystem 136 gegenüber dem ID-Token 106 authentifizieren muss und erst nachfolgend der Nutzer 102.
In dem ersten Fall ist der ID-Token 106 beispielsweise so ausgebildet, dass er nur durch Eingabe einer korrekten PIN oder eines korrekten biometrischen Merkmals durch den Nutzer 102 freigeschaltet wird. Erst diese Freischaltung ermöglicht den durch den Nutzer 102 freigeschaltet wird. Erst diese Freischaltung ermöglicht den Start der Programminstruktionen 132 und 134 und damit die Authentifizierung des ID-Provider-Computersystems 136.
Im zweiten Fall ist ein Start der Programminstruktionen 132 und 134 auch bereits möglich, wenn sich der Nutzer 102 noch nicht gegenüber dem ID-Token 106 authentifiziert hat. In diesem Fall sind beispielsweise die Programminstruktionen 134 so ausgebildet, dass das ID-Provider-Computersystem 136 erst dann einen Lesezugriff auf den geschützten Speicherbereich 124 zum Auslesen eines oder mehrerer der Attribute durchführen kann, nachdem von den Programminstruktionen 130 die erfolgreiche Authentifizierung auch des Nutzers 102 signalisiert worden ist.
Von besonderem Vorteil ist die Nutzbarmachung des ID-Tokens 106 für zum Beispiel E-Commerce und E-Government-Anwendungen, und zwar medienbruchfrei und rechtssicher aufgrund des durch die Notwendigkeit der Authentifizierung des Nutzers 102 und des ID-Provider-Computersystems 136 gegenüber dem ID-Token 106 gebildeten Vertrauensankers. Von besonderem Vorteil ist ferner, dass eine zentrale Speicherung der Attribute verschiedener Nutzer 102 nicht erforderlich ist, sodass die im Stand der Technik bestehenden Datenschutzprobleme hiermit gelöst sind. Was die Bequemlichkeit der Anwendung des Verfahrens betrifft, ist von besonderem Vorteil, dass eine vorherige Registrierung des Nutzers 102 zur Inanspruchnahme des ID-Provider-Computersystems 136 nicht erforderlich ist.
Von besonderem Vorteil ist ferner, dass für den Internetbrowser 112 jedes beliebige Browserprogramm verwendet werden kann, und dass keine Plugins für die Implementierung der Erfindung zwingend erforderlich sind.
Nach einer Ausführungsform der Erfindung sendet das Anwendungsprogramm 113 in dem Zeitraum zwischen HTTP GET 184 und HTTP 303 ein oder mehrfach HTTP 102 an den Internetbrowser 112, um ein Timeout des Internetbrowsers zu verhindern.
Die 2 zeigt ein entsprechendes Flussdiagramm. In dem Schritt 200 wird eine Dienst-Anforderung von dem Nutzer-Computersystem an das Dienst-Computersystem gesendet. Beispielsweise startet der Nutzer hierzu einen Internet-Browser des Nutzer-Computersystems und gibt eine URL zum Aufruf einer Webseite des Dienst-Computersystems ein. In die aufgerufene Webseite gibt der Nutzer dann seine Dienst-Anforderung ein, zum Beispiel zur Bestellung oder Auftragserteilung für einen Dienst oder ein Produkt.
In dem Schritt 202 spezifiziert das Dienst-Computersystem 150 daraufhin ein oder mehrere Attribute, welche es benötigt, um die Berechtigung des Nutzers für die Dienst-Anforderung zu prüfen. Insbesondere kann das Dienst-Computersystem solche Attribute spezifizieren, welche die digitale Identität des Nutzers 102 bestimmen. Diese Spezifizierung der Attribute durch das Dienst-Computersystem 150 kann fest vorgegeben sein oder je nach der Dienst-Anforderung im Einzelfall durch das Dienst-Computersystem 150 anhand vorgegebener Regeln bestimmt werden.
In dem Schritt 204 wird die Attributspezifikation, d. h. die in dem Schritt 202 erfolgte Spezifizierung der ein oder mehreren der Attribute, von dem Dienst-Computersystem an das ID-Provider-Computersystem übertragen, und zwar in Form eines SAML Request, vgl. SAML-Request 190 der 1.
Der SAML-Request beinhaltet neben der Attributspezifizierung den Identifikator, zum Beispiel die Session-ID 174 der Ausführungsform gemäß 1, sowie die Adresse, von der die SAML-Response später abrufbar sein soll, vergleiche die Adresse 178 in der Ausführungsform gemäß 1. Der SAML-Request wird von dem Dienst-Computersystem 150 über das Netzwerk 116 zunächst an das Anwendungsprogramm des Nutzer-Computersystems übertragen, welches den SAML-Request dann an das ID-Provider-Computersystem weiterleitet.
Um dem ID-Provider-Computersystem die Möglichkeit zu geben, Attribute aus seinem ID-Token auszulesen, authentifiziert sich der Nutzer in dem Schritt 206 gegenüber dem ID-Token.
In dem Schritt 208 wird eine Verbindung zwischen dem ID-Token und dem ID-Provider-Computersystem aufgebaut. Hierbei handelt es sich vorzugsweise um eine gesicherte Verbindung, beispielsweise nach einem so genannten Secure Messaging-Verfahren.
In dem Schritt 210 erfolgt zumindest eine Authentifizierung des ID-Provider-Computersystems gegenüber dem ID-Token über die in dem Schritt 208 aufgebaute Verbindung. Zusätzlich kann eine Authentifizierung auch des ID-Tokens gegenüber dem ID-Provider-Computersystem vorgesehen sein.
Nachdem sowohl der Nutzer als auch das ID-Provider-Computersystem erfolgreich gegenüber dem ID-Token authentifiziert worden sind, erhält das ID-Provider-Computersystem von dem ID-Token die Zugriffsberechtigung zum Auslesen der Attribute, in dem Schritt 212 sendet das ID-Provider-Computersystem ein oder mehrere Lesekommandos zum Auslesen der gemäß Attributspezifikation erforderlichen Attribute aus dem ID-Token. Die Attribute werden dann mittels Ende-zu-Ende-Verschlüsselung über die gesicherte Verbindung an das ID-Provider-Computersystem übertragen und dort entschlüsselt.
Die ausgelesenen Attributwerte werden in dem Schritt 214 von dem ID-Provider-Computersystem signiert. in dem Schritt 216 sendet das ID-Provider-Computersystem die signierten Attributwerte über das Netzwerk. Die signierten Attributwerte erreichen das Dienst-Computersystem entweder direkt oder über das Nutzer-Computersystem.
Im letzteren Fall kann der Nutzer die Möglichkeit haben, die signierten Attributwerte zur Kenntnis zu nehmen und/oder durch weitere Daten zu ergänzen. Es kann vorgesehen sein, dass die signierten Attributwerte gegebenenfalls mit den ergänzten Daten erst nach Freigabe durch den Nutzer von dem Nutzer-Computersystem an das Dienst-Computersystem weitergeleitet werden. Hierdurch ist größtmögliche Transparenz für den Nutzer hinsichtlich der von dem ID-Provider-Computersystem an das Dienst-Computersystem gesendeten Attribute hergestellt.
Die Signierung der ausgelesenen Attributwerte in dem Schritt 214 erfolgt, indem eine SAML-Response mit diesen Attributwerten von dem ID-Provider-Computersystem erzeugt wird. Die SAML-Response wird in dem Schritt 216 von dem ID-Provider-Computersystem zunächst gespeichert und nur die Verfügbarkeit der SAML-Response wird von dem ID-Provider-Computersystem an das Anwendungsprogramm signalisiert, nicht aber die SAML-Response selbst.
Das Anwendungsprogramm antwortet daraufhin auf den Aufruf des Internetbrowsers durch Signalisierung der Verfügbarkeit der SAML-Response, wobei hierbei auch die Adresse an den Internetbrowser übergeben wird. Der Internetbrowser ruft dann die SAML-Response von dem ID-Provider-Computersystem ab, sodass die SAML-Response zunächst an das Nutzer-Computersystem 100 übertragen wird. Dies hat den Vorteil, dass der Nutzer den Inhalt der SAML-Response zunächst zur Kenntnis nehmen kann und freigeben kann, bevor die SAML-Response dann von dem Internetbrowser an das Dienst-Computersystem weitergeleitet wird.
Die 3 zeigt ein entsprechendes UML-Diagramm.
In dem Schritt 0 will ein Nutzer auf eine Ressource (res) bei einem Dienstanbieter, wie zum Beispiel einem Internetshop, zugreifen. Hierzu richtet der Internetbrowser 112 in dem Schritt 0 ein Kommando HTTP GET an das Dienst-Computersystem 150. Das Dienst-Computersystem 150 antwortet hierauf mit einer HTTP-Response, zum Beispiel indem das Dienst-Computersystem innerhalb der aufgerufenen Internetseite einen lokalen Link auf das Anwendungsprogramm 113 übermittelt. Bei dem lokalen Link kann es sich um die Angabe der Parameter TCP-Portnummer und IP-Adresse des Anwendungsprogramms 113 handeln.
Ferner werden die Adresse 178, das heißt „tc” und die Session-ID 174, das heißt „id” mit der HTTP-Response von dem Dienst-Computersystem 150 an den Internetbrowser 112 übermittelt. Diese Informationen können zum Beispiel in einer Grafik oder einem Logo auf der Internetseite hinterlegt sein, welche der Nutzer durch Anklicken auswählen kann.
Wenn der Nutzer den lokalen Link auf der Internetseite auswählt, zum Beispiel durch einen Mausklick, so übermittelt daraufhin der Internetbrowser 112 in dem Schritt 1 durch ein HTTP GET die Daten tc und id an das Anwendungsprogramm 113.
Dieses leitet dann in dem Schritt 2 mittels HTTP GET die Adresse tc und den Identifikator id an das Dienst-Computersystem 150 weiter, um von dem Dienst-Computersystem 150 die Erzeugung des SAML-Requests anzufordern. Das Anwendungsprogramm 113 empfängt daraufhin in dem Schritt 3 den SAML-Request von dem Dienst-Computersystem 150 und leitet diesen in dem Schritt 4 mittels HTTP POST an das ID-Provider-Computersystem 136 weiter. Dieses antwortet daraufhin mit HTTP OK und liest dann die erforderlichen Attribute aus dem ID-Token, wie es an sich insbesondere aus DE 10 2008 000 067 B4 bekannt ist. Dies erfolgt in der in der 3 der Übersichtlichkeit halber nicht näher spezifizierten Schrittfolge 6. Während dieser Schrittfolge 6 kann einfach oder mehrfach HTTP 102 von dem Anwendungsprogramm 113 an den Internetbrowser 112 gesendet werden, um ein Timeout zu verhindern.
Nach einer eCard-API-Kommunikation zwischen dem Anwendungsprogramm 113 und dem Programminstruktionen 148 mit der signalisiert wird, dass die SAML-Response verfügbar ist, antwortet das Anwendungsprogramm 113 auf HTTP GET (vgl. Schritt 1) des Internetbrowsers 112 in dem Schritt 7 durch HTTP 303, wobei in dem Location Header Feld des HTTP Statuscode 303 die Adresse tc angegeben ist.
In dem Schritt 8 greift der Internetbrowser 112 dann durch HTTP GET mit Hilfe der Adresse auf die SAML-Response zu und erhält diese daraufhin durch HTTP POST in dem Schritt 9 von dem ID-Provider-Computersystem 136. Nachfolgend leitet der Internetbrowser in dem Schritt 10 die SAML-Response an das Dienst-Computersystem 150 weiter.
Bezugszeichenliste

100: Nutzer-Computersystem
102: Nutzer
104: Schnittstelle
106: ID-Token
108: Schnittstelle
110: Prozessor
112: Internetbrowser
113: Anwendungsprogramm
114: Netzwerk-Schnittstelle
116: Netzwerk
118: elektronischer Speicher
120: geschützter Speicherbereich
122: geschützter Speicherbereich
124: geschützter Speicherbereich
126: Speicherbereich
128: Prozessor
130: Programminstruktionen
132: Programminstruktionen
134: Programminstruktionen
136: ID-Provider-Computersystem
138: Netzwerk-Schnittstelle
140: Speicher
142: privater Schlüssel
144: Zertifikat
145: Prozessor
146: Programminstruktionen
148: Programminstruktionen
149: Programminstruktionen
150: Dienst-Computersystem
152: Netzwerk-Schnittstelle
154: Prozessor
156: Programminstruktionen
172: Speicher
174: Session-ID
176: Parameter
178: Adresse
180: HTTP GET
182: HTTP Response
184: HTTP GET
186: HTTP GET
188: Zuordnungstabelle
190: SAML-Request
192: SAML-Response
194: Signal

Claims

Verfahren zum Lesen zumindest eines in einem ID-Token (106) gespeicherten Attributs, wobei der ID-Token einem Nutzer (102) zugeordnet ist, mit folgenden Schritten: – Aufruf einer Internetseite eines Dienst-Computersystems (150) mit einem Internetbrowser (112) eines Nutzer-Computersystems (100) über ein Netzwerk (116), wobei die Internetseite zur Eingabe einer Auswahl eines Dienstes ausgebildet ist, – Eingabe der Auswahl des Dienstes auf der Internetseite durch den Nutzer, – Vergabe eines Identifikators (174; id) durch das Dienst-Computersystem zur Identifikation der Auswahl und Speicherung der Zuordnung des Identifikators zu der Auswahl, – Übertragung zumindest eines Parameters (176) zum Aufruf eines Anwendungsprogramms (113) des Nutzer-Computersystems, einer Adresse (178; tc) und des Identifikators von dem Dienst-Computersystem an den Internetbrowser des Nutzer-Computersystems über das Netzwerk, – Aufruf des Anwendungsprogramms des Nutzer-Computersystems mit Hilfe des zumindest einen Parameters durch den Internetbrowser und Eingabe der Adresse und des Identifikators in das Anwendungsprogramm, – Übertragung einer Anforderung von dem Anwendungsprogramm an das Dienst-Computersystem, wobei die Anforderung die Adresse und den Identifikator beinhaltet, – als Reaktion auf die Anforderung, Erzeugung eines SAML-Request (190) durch das Dienst-Computersystem, wobei der SAML-Request eine Attributspezifizierung zur Spezifizierung des zumindest einen Attributs beinhaltet, – Übertragung des SAML-Request von dem Dienst-Computersystem an das Anwendungsprogramm über das Netzwerk, – Weiterleitung des SAML-Request von dem Anwendungsprogramm an ein ID-Provider-Computersystem (136) über das Netzwerk, wobei das ID-Provider-Computersystem über das Netzwerk und das Nutzer-Computersystem einen Lesezugriff auf den ID-Token durchführt, um das zumindest eine Attribut gemäß der Attributspezifizierung aus dem ID-Token auszulesen, nachdem sich der Nutzer und das ID-Provider-Computersystem gegenüber dem ID-Token authentifiziert haben, – Erzeugung einer SAML-Response (192), welche das ausgelesene und von dem ID-Provider-Computersystem signierte zumindest eine Attribut und den Identifikator beinhaltet, durch das ID-Provider-Computersystem, – Speicherung der SAML-Response durch das ID-Provider-Computersystem zum Abrufen mittels der Adresse, – Signalisierung der Speicherung der SAML-Response von dem ID-Provider-Computersystem an das Anwendungsprogramm über das Netzwerk, – Antwort des Anwendungsprogramms auf den Aufruf durch den Internetbrowser durch Signalisierung der Speicherung der SAML-Response, – Abruf der SAML-Response durch den Internetbrowser mit Hilfe der Adresse über das Netzwerk, – Weiterleitung der SAML-Response von dem Internetbrowser an das Dienst-Computersystem über das Netzwerk, – Zuordnung der SAML-Response zu der Auswahl des Dienstes mit Hilfe des Identifikators durch das Dienst-Computersystem, – Prüfung durch das Dienst-Computersystem, ob das zumindest eine Attribut der SAML-Response ein Kriterium erfüllt als Voraussetzung für die Erbringung des Dienstes.
Verfahren nach Anspruch 1, wobei es sich bei den Parametern zum Aufruf des Anwendungsprogramms um eine Transmission Control Protocol(TCP)-Portnummer und eine Internetprotokoll(IP)-Adresse des Anwendungsprogramms handelt, wobei das Anwendungsprogramm durch Senden der Adresse und des Identifikators an die Portnummer und Adressierung mit der IP-Adresse aufgerufen wird.
Verfahren nach Anspruch 1 oder 2, wobei das Anwendungsprogramm und das ID-Provider-Computersystem jeweils ein Application Programming Interface (API) aufweisen und die APIs vorzugsweise jeweils Teil des eCard-API-Framework sind.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Signalisierung der Speicherung der SAML-Response über die APIs und das Netzwerk erfolgt.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der Aufruf des Anwendungsprogramms mit der Adresse und dem Identifikator durch ein HTTP GET-Kommando erfolgt, welches nach dem Aufruf von dem Anwendungsprogramm an das Dienst-Computersystem zur Übertragung der Anforderung weitergeleitet wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Anwendungsprogramm auf den Aufruf mit dem HTTP-Statuscode 303 antwortet, wobei in dem Location-Header-Feld des HTTP-Statuscode 303 die Adresse angegeben ist, sodass der Internetbrowser mit Hilfe eines HTTP GET-Kommandos die SAML-Response von der Adresse abruft.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Anwendungsprogramm in dem Zeitraum zwischen dem Empfang des Aufrufs von dem Internetbrowser und der Antwort auf den Aufruf ein oder mehrfach ein Signal an den Internetbrowser übersendet, um einen Timeout des Internetbrowsers aufgrund der ausbleibenden Antwort zu verhindern.
Verfahren nach Anspruch 7, wobei es sich bei dem Signal um einen HTTP 102 Statuscode handelt.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Dienst-Computersystem die Attributspezifizierung in Abhängigkeit von der Auswahl des Dienstes bestimmt.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das ID-Provider-Computersystem zur gleichzeitigen Verarbeitung mehrerer SAML-Requests für verschiedene Auswahlen von Diensten ausgebildet ist, wobei der Identifikator jeweils eindeutig einen SAML-Request, die entsprechende SAML-Response und den ausgewählten Dienst, für welche das zumindest eine Attribut ausgelesen wird, zuordnet.
Verfahren nach einem der vorhergehenden Ansprüche, wobei es sich bei dem Identifikator um eine Session-ID einer aufgrund des Aufrufs der Internetseite aufgebauten Session handelt.
Verfahren nach einem der vorhergehenden Ansprüche, wobei es sich bei dem ID-Token ein tragbares elektronisches Gerät handelt, der einen Datenspeicher zur Speicherung des zumindest einen Attributs und eine Kommunikationsschnittstelle zum Auslesen des zumindest einen Attributs aufweist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der ID-Token z. B. als USB-Stick oder als Dokument ausgebildet ist, insbesondere als Wert- oder Sicherheitsdokument, insbesondere papierbasiert und/oder kunststoffbasiert, wie zum Beispiel als Ausweisdokument, insbesondere Reisepass, Personalausweis, Visum, Führerschein, Fahrzeugschein, Fahrzeugbrief, Firmenausweis, elektronische Gesundheitskarte oder anderes ID-Dokument, als Chipkarte, Zahlungsmittel, insbesondere Bankkarte, Kreditkarte oder Banknote, Frachtbrief oder sonstiger Berechtigungsnachweis.
Computerprogrammprodukt, insbesondere digitales Speichermedium, mit ausführbaren Instruktionen zur Durchführung eines Verfahrens nach einem der vorhergehenden Ansprüche.
Datenverarbeitungssystem mit einem ID-Provider-Computersystem (136), wobei das ID-Provider-Computersystem folgendes aufweist: – Mittel (138) zum Empfang eines SAML-Request (190) von einem Anwendungsprogramm (113) eines Nutzer-Computersystems (100) über ein Netzwerk (116), wobei der SAML-Request eine Attributspezifizierung zumindest eines aus einem ID-Token auszulesenden Attributs, eine Adresse und einen Identifikator beinhaltet, – Mittel (142, 144, 146) zur Authentifizierung des ID-Provider-Computersystems gegenüber dem ID-Token über das Netzwerk, – Mittel (148) zur Durchführung eines Lesezugriffs zum Lesen des zumindest einen in dem ID-Token gespeicherten Attributs gemäß der Attributspezifizierung über das Netzwerk nach erfolgreicher Durchführung der Authentifizierung, – Mittel (145, 148) zur Erzeugung einer SAML-Response (192), welche das zumindest eine von dem ID-Provider-Computersystem ausgelesene und signierte Attribut, den Identifikator und eine Adresse beinhaltet, – Mittel (145, 140) zur Speicherung der SAML-Response in einem elektronischen Speicher (140) des ID-Provider-Computersystems, sodass mit Hilfe der Adresse die SAML-Response durch einen Internetbrowser des Nutzer-Computersystems über das Netzwerk abrufbar ist, sodass sie über das Netzwerk von dem ID-Provider-Computersystem an das Nutzer-Computersystem übertragen wird, mit zumindest einem Nutzer-Computersystem (100), auf welchem das Anwendungsprogramm und der Internetbrowser installiert sind, sowie einer Schnittstelle (104) für den ID-Token zur Durchführung des Lesezugriffs von dem ID-Provider-Computersystem über das Nutzer-Computersystem, mit einem Dienst-Computersystem (150), von dem eine Internetseite aufrufbar ist, wobei die Internetseite zur Eingabe einer Auswahl eines Dienstes ausgebildet ist, wobei das Dienst-Computersystem folgendes aufweist: – Mittel (152, 156) zum Empfang einer Eingabe des Nutzers zur Auswahl des Dienstes auf der Internetseite, – Mittel (156) zur Vergabe eines Identifikators (174) durch das Dienst-Computersystem zur Identifikation der Auswahl und Speicherung der Zuordnung des Identifikators zu der Auswahl, – Mittel (152, 156) zur Übertragung zumindest eines Parameters (176) zum Aufruf eines Anwendungsprogramms des Nutzer-Computersystems, einer Adresse (178) und des Identifikators von dem Dienst-Computersystem an den Internetbrowser des Nutzer-Computersystems über das Netzwerk, – Mittel (152, 156) zum Empfang einer Anforderung von dem Anwendungsprogramm, wobei die Anforderung die Adresse und den Identifikator beinhaltet, – Mittel (156) zur Erzeugung eines SAML-Request (190) durch das Dienst-Computersystem als Reaktion auf die Anforderung, wobei der SAML-Request eine Attributspezifizierung zur Spezifizierung des zumindest einen Attributs beinhaltet, – Mittel (152, 154, 156) zur Übertragung des SAML-Request von dem Dienst-Computersystem an das Anwendungsprogramm über das Netzwerk, – Mittel (152, 154, 156) zum Empfang der SAML-Response (192) von dem Internetbrowser über das Netzwerk, – Mittel (156) zur Zuordnung der SAML-Response zu der Auswahl des Dienstes mit Hilfe des Identifikators durch das Dienst-Computersystem, – Mittel (156) zur Prüfung durch das Dienst-Computersystem, ob das zumindest eine Attribut der SAML-Response ein Kriterium erfüllt als Voraussetzung für die Erbringung des Dienstes.