DE112011102129T5

DE112011102129T5 - Sicherheitsmodell für Abläufe, die sichere Fremddienste zusammenführen

Info

Publication number: DE112011102129T5
Application number: DE112011102129T
Authority: DE
Inventors: Paula Austel; Suresh Chari; Francisco Curbera; Matthew Duftler; Rania Khalaf; Florian Rosenberg
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2010-06-25
Filing date: 2011-03-09
Publication date: 2013-06-06
Anticipated expiration: 2031-03-10
Also published as: JP2013538380A; GB2495448A; WO2011162838A1; US20110321131A1; CN102893552A; US9189649B2; DE112011102129B4; GB201301106D0

Abstract

Verfahren, System und Computerprogrammprodukt für ein Sicherheitsmodell für Abläufe, die sichere Fremddienste zusammenführen. In einer Ausführungsform wird ein Ablaufmodell, das in einer Ablaufsprache beschrieben ist, bereitgestellt und ist konfiguriert, um Sicherheitsanforderungen einer kombinierten Anwendung, die geschützte Daten von zwei oder mehr externen Netzwerkressourcen integriert, zu deklarieren. Das Verfahren beinhaltet außerdem das Bereitstellen eines Authentifizierungsdienstes, der auf wenigstens einem sicheren Servercomputer ausgeführt wird. Der Authentifizierungsdienst ist konfiguriert, um eine Benutzer-Authentifizierung und -Berechtigung durchzuführen, um auf die geschützten Daten in der externen Netzwerkressource im Auftrag der kombinierten Anwendung, die auf wenigstens einem Host-Servercomputer gemäß der Ablaufsprache ausgeführt wird, zuzugreifen.

Description

HINTERGRUND
Verschiedene Ausführungsformen, die hier beschrieben werden, beziehen sich im Allgemeinen auf Systeme und insbesondere auf ein Sicherheitsmodell für Abläufe, die sichere Fremddienste zusammenführen.
Mashups sind ein Verfahren zum Erzeugen neuer Webanwendungen, die eine Inhalts-, Präsentations- und Anwendungsfunktionalität von disparaten Webquellen kombinieren. Diese enthalten das miteinander ”Vermischen” von mehreren Diensten und Quellen wie etwa REST- oder SOAP-Diensten, Feeds (RSS oder ATOM) oder reinen XML- oder HTML-Quellen.
Zwei unterschiedliche Typen von Mashups sind gegenwärtig dominierend, Verbraucher-Mashups und Firmen-Mashups. Verbraucher-Mashups sind meistens für den privaten Gebrauch, wobei sie Daten von mehreren Ressourcen kombinieren, indem sie unter Verwendung einer gemeinsamen Schnittstelle vereint werden. Firmen-Mashups kombinieren verschiedene Quellen von wenigstens einer Ressource in einer Firmenumgebung. Firmen-Mashups haben ein enormes Potenzial, indem sie zur Verminderung von Entwicklungskosten eine Assemblierung gegenüber einer Entwicklung und die Bereitstellung einer neuen Lösung innerhalb kürzerer Zeitperioden unterstützen.
ZUSAMMENFASSUNG
Eine beispielhafte Ausführungsform der vorliegenden Erfindung ist ein Verfahren zum Zugreifen auf Daten. Das Verfahren enthält das Empfangen eines Ablaufmodells, das in einer Ablaufsprache beschrieben wird. Das Ablaufmodell ist konfiguriert, um Sicherheitsanforderungen einer kombinierten Anwendung, die geschützte Daten von zwei oder mehr externen Netzwerkressourcen integriert, zu deklarieren. Das Verfahren beinhaltet außerdem das Ausführen eines Authentifizierungsdienstes an wenigstens einem sicheren Servercomputer. Der Authentifizierungsdienst ist konfiguriert, um eine Benutzer-Authentifizierung und -Berechtigung durchzuführen, um auf die geschützten Daten in den externen Netzwerkressourcen im Auftrag der kombinierten Anwendung, die auf wenigstens einem Host-Servercomputer gemäß der Ablaufsprache ausgeführt wird, zuzugreifen.
Eine weitere beispielhafte Ausführungsform der vorliegenden Erfindung enthält ein System zum Zugreifen auf Daten. Das System enthält ein Ablaufmodell, das in einer Ablaufsprache beschrieben wird. Das Ablaufmodell ist konfiguriert, um Sicherheitsanforderungen einer kombinierten Anwendung, die geschützte Daten von zwei oder mehr externen Netzwerkressourcen integriert, zu deklarieren. Das System enthält außerdem einen Authentifizierungsdienst, der auf wenigstens einem sicheren Servercomputer ausgeführt wird. Der Authentifizierungsdienst ist konfiguriert, um eine Benutzer-Authentifizierung und -Berechtigung durchzuführen, um im Auftrag der kombinierten Anwendung, die gemäß der Ablaufsprache auf wenigstens einem Host-Servercomputer ausgeführt wird, auf die geschützten Daten zuzugreifen.
Eine noch weitere beispielhafte Ausführungsform ist ein Computerprogrammprodukt zum Zugreifen auf Daten. Das Computerprogrammprodukt enthält das Empfangen eines Ablaufmodells, das in einer Ablaufsprache beschrieben wird. Das Ablaufmodell ist konfiguriert, um Sicherheitsanforderungen einer kombinierten Anwendung, die geschützte Daten von zwei oder mehr externen Netzwerkressourcen integriert, zu deklarieren. Das Computerprogrammprodukt enthält außerdem Code, der konfiguriert ist, um eine Anforderung an einen Authentifizierungsdienst auszugeben, der auf wenigstens einem sicheren Servercomputer ausgeführt wird, um eine Benutzer-Authentifizierung und -Berechtigung auszuführen, um im Auftrag der kombinierten Anwendung gemäß der Ablaufsprache auf die geschützten Daten in den externen Netzwerkressourcen zuzugreifen.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Der Gegenstand, der als die Erfindung betrachtet wird, wird am Ende der Beschreibung in den Ansprüchen besonders hervorgehoben und eindeutig beansprucht. Die vorhergehenden und weiteren Aufgaben, Merkmale und Vorteile der Erfindung werden aus der folgenden genauen Beschreibung deutlich, die in Verbindung mit den beigefügten Zeichnungen erfolgt, worin:
1 ein beispielhaftes System zum Zugreifen auf Daten veranschaulicht, wie durch die vorliegende Erfindung vorgesehen.
2 einen beispielhaften Ablaufplan des Verfahrens zum Zugreifen auf Daten zeigt, wie durch die vorliegende Erfindung vorgesehen.
3 ein beispielhaftes Szenario der Verwendung des Systems und des Verfahrens zum Zugreifen auf Daten zeigt, wie durch die vorliegende Erfindung vorgesehen.
4 eine beispielhafte Ablaufmodell-Auflistung von dem beispielhaften Szenario von 3 ist.
5 eine Übersicht von Sicherheitslösungen ist, die die beispielhafte Ausführungsform der vorliegenden Erfindung wie in 3 gezeigt implementieren.
6 eine beispielhafte Ablaufmodell-Auflistung von dem beispielhaften Szenario von 3 eines beispielhaften Sicherheitserweiterungselements ist.
7A eine beispielhafte Webseite des Browsers eines Benutzers ist, wenn von dem beispielhaften Szenario von 3 zu einem sicheren Authentifizierungsdienst (SAS, Secure Authorization Service) umgeleitet wird.
7B eine beispielhafte Authentifizierungs-Webseite des Browsers eines Benutzers von dem beispielhaften Szenario von 3 ist.
GENAUE BESCHREIBUNG
Die vorliegende Erfindung wird unter Bezugnahme auf Ausführungsformen der Erfindung beschrieben. In der gesamten Beschreibung der Erfindung erfolgt die Bezugnahme auf die 1 bis 7B.
Aspekte der Erfindung beziehen sich auf ein Sicherheitsmodell für Mashups, die sichere Fremddienste zusammenführen. Gegenwärtigen Firmen-Mashup-Tools fehlt die Fähigkeit, unterschiedliche Dienste in einem Mashup auf sichere Weise zu verbrauchen und zu integrieren, wenn sie in Bezug auf Authentifizierung und Berechtigung vollkommen verschiedenartige Sicherheitsanforderungen aufweisen. Folglich können viele Mashup-Tools lediglich sicherheitsfreie Dienste und Datenquellen oder Hardcode-Authentifizierungsdaten in dem Mashup-Code integrieren. Das stellt in Firmen-Umgebungen ein Problem dar, da Benutzer stärker abgeneigt sind, ihre Authentifizierungsinformationen an Fremd-Ressourcen zu geben (die Firmenpolitik kann dies tatsächlich sogar verbieten), die typischerweise kundenspezifische Sicherheitsanforderungen aufweisen. Des Weiteren erfordern kumulierte sichere Dienste unterschiedliche Berechtigungsnachweise von verschiedenen Benutzern über unterschiedliche Protokolle. Ressourcen können jedes von mehreren Authentifizierungsprotokollen unterstützen wie etwa HTTP-Basic-Authentication, kundenspezifische Anwendungsschlüssel und weitere Web-2.0-ähnliche Protokolle wie OpenID und OAuth.
Ausführungsformen der vorliegenden Erfindung stellen eine Unterstützung für Firmen-Mashups bereit, die es einem Benutzer ermöglichen, Daten sowohl von sicheren als auch unsicheren Ressourcen in einem Netzwerk zusammenzuführen, wobei jede sichere Ressource potenziell ein anderes Sicherheitsprotokoll verwendet.
1 veranschaulicht ein beispielhaftes System 100 zum Zugreifen auf Daten wie durch die vorliegende Erfindung vorgeschlagen. Es wird angemerkt, dass das gezeigte System 100 lediglich ein Beispiel von verschiedenen Anordnungen der vorliegenden Erfindung ist und nicht als Einschränkung der Erfindung auf eine bestimmte Konfiguration interpretiert werden sollte.
In einer Ausführungsform enthält das System 100 einen Host-Servercomputer 102 und einen sicheren Servercomputer 110. Auf dem Host-Servercomputer 102 läuft eine kombinierte Anwendung 104. Ein Ablaufmodell 106, das in einer Ablaufsprache beschrieben wird, ist konfiguriert, um Sicherheitsanforderungen der kombinierten Anwendung 104, die geschützte Daten 118 von zwei oder mehr externen Ressourcen 116 integriert, zu deklarieren. Somit sind Abläufe eine Möglichkeit, Mashups zu repräsentieren/materialisieren und auszuführen.
Die kombinierte Anwendung 104, die auf dem Host-Servercomputer 102 laufen kann, kann das Ablaufmodell 106 enthalten. Die kombinierte Anwendung 104 kann in einer kompilierten oder interpretativen Sprache, zu der die Ablaufsprache gehört, geschrieben sein. Die Ablaufsprache kann eine kompilierte oder interpretative Sprache sein, die eine XML-basierte Sprache, zu der Bite oder eine erweiterte Version der Bite-Sprache gehört, enthalten kann. Für weitere Informationen über die Bite-Sprache wird der Leser auf Francisco Curbera, Matthew Duftler, Rania Khalaf, Douglas Lovell, Bite: Workflow Composition for the Web, International Conference an Service Oriented Computing (ICSOC 2007), Springer LNCS, Vienna, Austria, Sept. 17–20, 2007 verwiesen. Weitere Ausführungsformen der kombinierten Anwendung 104 enthalten einen Sicherheits-Handler 108. Der Sicherheits-Handler 108 kann ein Modul in der kombinierten Anwendung 104 sein, das mit einem Authentifizierungsdienst 112 zusammenwirkt. Der Sicherheits-Handler 108 kann mit dem Authentifizierungsdienst 112 über mehrere Authentifizierungsprotokolle zusammenwirken, zu denen OAuth, HTTP-Basic-Authentification und AppID gehören, die jedoch nicht darauf beschränkt sind, um eine Unterstützung für verschiedene Sicherheitsmechanismen im Zieldienst bereitzustellen.
In einer Ausführungsform der Erfindung enthält die kombinierte Anwendung 104 wenigstens eine Ablaufinstanz des Ablaufmodells 106. Der Ablauf kann in der Ablaufsprache geschrieben sein. In einer Ausführungsform der vorliegenden Erfindung behält die Ablaufinstanz ihren Ausführungszustand bei, wenn die kombinierte Anwendung 104 mit dem Authentifizierungsdienst 112 Daten austauscht.
Der sichere Server 110 muss sich in einer zuverlässigen Umgebung befinden, die durch Authentifizierungs- und Zugriffssteuerungsregeln geschützt ist. Auf dem sicheren Servercomputer 110 läuft der Authentifizierungsdienst 112. Der Authentifizierungsdienst 112 ist konfiguriert, um Authentifizierung und Berechtigung des Benutzers zu leiten, um im Auftrag der kombinierten Anwendung 104 auf die geschützten Daten 118 auf den externen Ressourcen 116 zuzugreifen. Zu externen Ressourcen 116 gehören alle Ressourcen, die in einem externen Computer entweder gesichert oder ungesichert zur Verfügung stehen. Zu den geschützten Daten 118 gehören Feeds wie etwa RSS oder Atom, Dienste wie REST oder SOAP, HTML- oder XML-Quellen oder computerzugängliche Dateien wie etwa Bilder oder Dokumente.
In einer Ausführungsform werden Benutzer-Berechtigungsnachweise 114 in dem Authentifizierungsdienst 112 gespeichert. Die Benutzer-Berechtigungsnachweise 114 können Passwörter, Benutzernamen oder Tokens, die Kenninformationen speichern, enthalten.
Der Host-Servercomputer 102 ist über ein Netzwerk 120 mit dem sicheren Servercomputer 110 verbunden. Das Netzwerk 120 kann ein Typ von verschiedenen Netzwerktypen sein, die in der Technik bekannt sind, wozu Lokalbereich-Netzwerke (LANs), Weitbereich-Netzwerke (WANs), leitungsgestützte und/oder drahtlose Netzwerke gehören. Das Netzwerk 120 kann verschiedene in der Technik bekannte Konfigurationen verwenden, wozu als Beispiel und ohne Einschränkung TCP/IP, Wi-Fi^®, Bluetooth^®-Piconetze, Tokenring, optische und Mikrowellen-Netzwerke gehören. Wi-Fi ist ein eingetragenes Warenzeichen der Wi-Fi Alliance, die in Austin, Texas ansässig ist. Bluetooth ist ein eingetragenes Warenzeichen der Bluetooth SIG, Inc., die in Bellevue, Washington ansässig ist.
2 zeigt einen beispielhaften Ablaufplan 200 eines Verfahrens zum Zugreifen auf Daten wie durch die vorliegende Erfindung vorgeschlagen. Jede Ablaufaktivität kann Operationen 204 bis 218 bewirken, falls Sicherheit erforderlich ist. Das heißt, die Operationen können ausgeführt werden, wenn die Ablaufaktivität ein Sicherheitselement aufweist und abgehend ist. Das Verfahren beginnt im Block 202 und enthält das Empfangen einer Ablaufsprache, um Sicherheitsanforderungen einer kombinierten Anwendung, die geschützte Daten von zwei oder mehr externen Netzwerkressourcen integriert, zu deklarieren. Das Deklarieren von Sicherheitsanforderungen kann das Verwenden eines Sicherheitserweiterungselements in der Ablaufsprache enthalten.
Im Block 204 enthält das Verfahren das Bereitstellen eines Authentifizierungsdienstes, um eine Benutzer-Authentifizierung und -Berechtigung durchzuführen, um auf die geschützten Daten in den externen Netzwerkressourcen im Auftrag der kombinierten Anwendung, die auf einem Host-Servercomputer gemäß der Ablaufsprache ausgeführt wird, zuzugreifen.
Das Verfahren enthält ferner im Block 205 das Verbinden mit dem Authentifizierungsdienst von der kombinierten Anwendung. Das kann ausgeführt werden durch die Verwendung von allgemeinen Sicherheitsprotokollen wie etwa des OAuth-Protokolls.
OAuth ist ein allgemein bekanntes und immer populärer werdendes Protokoll für webbasierte Anwendungen und implementiert eine nahtlose Möglichkeit der Handhabung von Authentifizierung und Berechtigung zwischen einem Verbraucher und einem Anbieter. Der Verbraucher ist in diesem Szenario die Bite-Maschine und der Anbieter ist der eigentliche SAS. Ein OAuth-Anbieter muss drei verschiedene Anforderungs-URLs bereitstellen: (1) eine URL des Anforderungs-Token (relative URL/request token); (2) eine URL der Benutzer-Authentifizierung (/authorize); und (3) eine URL des Zugriffs-Token (/access token). Eine typische OAuth-Authentifizierung und Berechtigung wird folgendermaßen gehandhabt: Zunächst fordert ein Verbraucher einen Anforderungs-Token unter Verwendung der URL des Anforderungs-Token (1), indem mehrere OAuth-spezifische Parameter gesendet werden, wie etwa ein im Voraus ausgehandelter Verbraucherschlüssel zum Identifizieren der Verbraucheranwendung, Zeitstempel, Einmalschlüssel, Signatur usw. Falls alle Parameter korrekt und verifizierbar sind, gibt der Dienstanbieter einen nicht autorisierten Anforderungs-Token aus. Wenn der Anforderungs-Token von dem Verbraucher empfangen wird, kann der Browser des Benutzers zu dem Dienstanbieter umgeleitet werden, um Authentifizierung und Berechtigung zu erhalten. Diese Berechtigung gewährleistet, dass der Benutzer, der hinter dem Browser steht, ausdrücklich sicherstellt, dass die Web-Anwendung des Verbrauchers auf die Ressourcen des Dienstanbieters in seinem Namen zugreifen darf. Nachdem die Berechtigung ausgeführt wurde, kann der Dienstanbieter den Benutzer wieder zu der Verbraucheranwendung umleiten (unter Verwendung einer Rückruf-URL). Schließlich muss der Verbraucher den Anforderungs-Token gegen einen Zugriffs-Token beim Dienstanbieter austauschen. Das wird typischerweise gewährt, wenn der Benutzer die Authentifizierung und Berechtigung in dem vorhergehenden Schritt erfolgreich ausgeführt hat. Dieser Zugriffs-Token ist einer der OAuth-Parameter, der (neben anderen wie dem Verbraucherschlüssel, Zeitstempel, Signatur usw.) mit jeder weiteren Anforderung an den geschützten Dienst gesendet werden muss.
Das Verfahren enthält im Schritt 206 das Ausgeben einer Anforderung an den Authentifizierungsdienst im Auftrag der kombinierten Anwendung. Diese Anforderung kann ausgegeben werden, wenn die kombinierte Anwendung Daten benötigt, die in einer Fremdressource gehalten werden. Diese Daten können des Weiteren geschützt sein. Die Anforderung kann durch die Verwendung eines Sicherheits-Handler-Moduls in der kombinierten Anwendung ausgegeben werden.
Im Block 208 enthält das Verfahren das Abrufen von Protokollinformationen über eine der zwei oder mehr externen Netzwerkressourcen. Protokollinformationen können abgerufen werden durch das Anfordern von Protokollinformationen von der externen Ressource oder durch hartes Codieren von Sicherheitsinformationen in ein Sicherheits-Handler-Modul oder in den Authentifizierungsdienst.
Im Block 210 enthält das Verfahren das Umleiten eines Benutzers von der kombinierten Anwendung zu dem Authentifizierungsdienst, um Beglaubigungen anzufordern. Dieser Schritt variiert in Abhängigkeit von dem Protokoll. Wenn das Protokoll Http-Basic-Authentication oder AppID ist, zeigt der SAS ein Formular an, um die Benutzer-Berechtigungsnachweise zu sammeln und speichert diese Berechtigungsnachweise sicher in dem SAS. Wenn das Protokoll für den Fremddienst OAuth ist, führt der SAS das OAuth-Protokoll mit dem Fremddienst aus und der Benutzer wird durch den SAS zu dem Fremddienst umgeleitet, so dass die Benutzer-Berechtigungsnachweise lediglich in den Fremddienst eingegeben und niemals in dem SAS gespeichert werden.
Der Block 210 kann des Weiteren das Umleiten eines Benutzers enthalten, der gegenwärtig mit der kombinierten Anwendung zusammenwirkt, indem der Browser des Benutzers zu einer Web-Seite des Authentifizierungsdienstes umgeleitet wird. In einer Ausführungsform der vorliegenden Erfindung kann das ausgeführt werden, indem der Benutzer über einen asynchronen Benachrichtigungsdienst kontaktiert wird, wenn der Benutzer gegenwärtig nicht mit der kombinierten Anwendung verbunden ist. Der asynchrone Benachrichtigungsdienst kann z. B. eine e-Mail, eine Sofortnachricht oder eine Mobiltelefon-Textnachricht enthalten.
Die transparente Unterstützung einer sicheren Authentifizierung und Berechtigung von verschiedenen Fremddiensten durch die OAuth-Schnittstelle des SAS erfordert eine Erweiterung des OAuth-Protokolls. Das ermöglicht, dass der SAS für verschiedene andere Authentifizierungsprotokolle als ein ”sicherer Proxy” wirkt. Dazu benötigt der SAS wenigstens die URL und den Authentifizierungstyp des Zieldienstes. Da diese Informationen in der Aktivitätsspezifikation und der Sicherheitserweiterung in einem Bite-Ablauf (z. B. 4, Zeilen 18 bis 23) zur Verfügung stehen, müssen sie lediglich an den SAS gesendet werden, um eine transparente Fremddienst-Authentifizierung zu ermöglichen. Somit werden mehrere Anforderungsparameter hinzugefügt, wenn die Bite-Maschine einen Anforderungs-Token bei dem SAS anfordert.
Im Block 214 enthält das Verfahren das Erhalten von Benutzer-Berechtigungsnachweisen von dem Authentifizierungsdienst. Das kann realisiert werden durch das Umlenken von Benutzern zu dem Fremddienst, um nach Berechtigungsnachweisen zu fragen. Wenn jedoch wie früher erwähnt das Protokoll für den Fremddienst OAuth ist, führt der SAS das OAuth-Protokoll mit dem Fremddienst aus und der Benutzer wird durch den SAS zu dem Fremddienst umgeleitet, so dass die Benutzer-Berechtigungsnachweise bei dem Fremddienst lediglich eingegeben und niemals im SAS gespeichert werden.
Im Block 216 schafft das Verfahren eine Verbindung zu einer der zwei oder mehr externen Netzwerkressourcen von dem Authentifizierungsdienst. Der Authentifizierungsdienst kann die Benutzer-Berechtigungsnachweise aufweisen und kann den Mechanismen des speziellen Sicherheitsprotokolls oder den Protokollen, die durch die Fremdressource verwendet werden, folgen. Zusätzlich enthält das Verfahren im Block 218 das Empfangen geschützter Daten von dem Authentifizierungsdienst. Der Authentifizierungsdienst kann als eine Zwischenstelle für Daten sowie als Sicherheit wirken.
3 zeigt ein beispielhaftes Szenario der Verwendung des Systems und des Verfahrens zum Zugreifen auf Daten wie durch die vorliegende Erfindung vorgeschlagen. Ein Szenario eines Firmen-Mashup wird verwendet, um das Problem und Konzepte zu veranschaulichen. Bei diesem Szenario möchte der Einstellungsmanager bei Acme Inc (links) eine neue Position besetzen. Er verwendet das Firmen-Mashup, um das Vorstellungsgespräch mit dem Kandidaten zu planen und seinen Lebenslauf zu erhalten (unten rechts). Dazu bewirkt das Mashup zuerst einen Aufruf des Kalenders des Einstellungsmanagers, der über Google-Kalender zur Verfügung steht. Dann erfolgt eine Verzweigung. Der untere Zweig antwortet auf den anfänglichen Aufruf und der obere Zweig schickt die verfügbaren Termine zu dem Bewerbungsgespräch-Planungsdienst von Acme, sendet dem Kandidaten per e-Mail den endgültigen Zeitschlitz, der von diesem Dienst zurückgegeben wird, und einen Link, der verfolgt werden sollte, um den Prozess abzuschließen. Wenn der Kandidat den Link anklickt, findet er ein Formular, in welches er seine persönlichen Daten einträgt und an das er seinen Lebenslauf anfügt. Das Mashup platziert schließlich den Lebenslauf in den Dienst zur gemeinsamen Dateinutzung ”Files” in LotusLive Engage, einer Online-Kollaborationslösung.
Das Zusammenwirken mit mehreren sicheren Fremddiensten erfordert unterschiedliche Gruppen von Berechtigungen und Authentifizierungsprotokollen. Google-Kalender verwendet z. B. das OAuth-Protokoll, der Planungsdienst von Acme verwendet HTTP-Basic-Authentication und der Dateidienst erfordert einen Anwendungsschlüssel und den Benutzer, zu dessen Speichereinrichtung die Datei hinzugefügt werden sollte. Der Aufruf des Google-Kalenders und der Aufruf des Datei-Dienstes erfordern beide, dass das Mashup im Auftrag des Benutzers mit ihnen zusammenwirkt, möglicherweise nachdem der Benutzer nicht mehr in dem System angemeldet ist.
4 ist eine beispielhafte Programmauflistung des Ablaufmodells von dem beispielhaften Szenario in 3. Die Geschäfts-Mashup-Plattform (BMP, Business Mashup Platform) stellt eine Umgebung der Host-Entwicklung bereit für eine rasche Entwicklung von situationsbedingten Geschäftsprozessen oder Firmen-Mashups. Die grafische Mashup-Entwicklung ist browsergestützt, wobei ein Editor des BPMN-Stils, ein Formularentwickler und ein Katalog von Erweiterungsaktivitäten, die dem Entwickler in einer Palette angeboten werden, vorteilhaft genutzt werden. Nachdem ein Mashup vollständig spezifiziert wurde, ermöglicht BMP eine Ein-Klick-Entwicklung von Mashups, die sofort aufgerufen werden können. Im Hintergrund wird Bite-Code erzeugt und auf dem Server ausgeführt.
Bite ist eine XML-basierte, auf REST ausgerichtete Kompositionssprache, die entworfen ist, um die Implementierung von leichten und erweiterbaren Abläufen zu ermöglichen. Das Prozessmodell implementiert eine Teilmenge der WS-BPEL-Ausführungssemantik, die aus einem ebenen Graphen (Ausnahme für Schleifen) besteht, der unteilbare Aktionen (Aktivitäten) und Links zwischen ihnen enthält. Schleifen können unter Verwendung einer zweckbestimmten Schleifenaktivität erzeugt werden, das einzige Konstrukt, das andere Aktivitäten enthalten darf. Eine Graphen-Ausführungslogik wird bei Links des bedingten Übergangs zwischen Aktivitäten codiert. Eine Fehlerbehandlung wird durch spezielle Fehlerlinks zu Fehlerbehandlungsaktivitäten bereitgestellt. Bite stellt eine kleine Gruppe von integrierten Aktivitäten dar: (1) grundlegende HTTP-Kommunikations-Stammfunktionen zum Empfangen und Beantworten von HTTP-Anforderungen (receiveGET|POST, replyGET|POST, receive-replyGET|POST) und Bewirken von HTTP-Anforderungen an externe Dienste (GET, POST, PUT, DELETE), (2) Dienstprogramm-Aktivitäten zum Erwarten oder Aufrufen von Lokalcode, (3) Steuerungshilfsmittel wie etwa externe Auswahl und Schleifen.
Ein Bite-Ablauf ruft beide externe Dienste auf und stellt sich selbst als Dienst bereit. Das Senden einer HTTP-POST-Anforderung an eine Basis-URL des Ablaufs hat die Erzeugung einer neuen Ablaufinstanz zur Folge, die einer neuen Instanz-URL zugewiesen ist. Diese Instanz-URL wird in dem HTTP-Positions-Kopffeld der Antwort zurückgegeben. Die Instanz-URL enthält eine Ablauf-Kennung, die für eine Korrelation von nachfolgenden Anforderungen mit diesem Ablauf verwendet wird.
Jede Ablauf-Instanz kann mehrere Empfangsaktivitäten, die mehreren Eintrittspunkten entsprechen, definieren. Diese Aktivitäten bieten zusätzliche URLs als logische Adressen der eingebetteten Ressourcen der Instanz. POST-Anforderungen, die an diese URLs gerichtet werden, werden zu den einzelnen Empfangsaktivitäten in dem Ablaufmodell unter Verwendung der relativen URLs, die in dem URL-Attribut der Aktivitäten gespeichert sind, geleitet. Dieser Mechanismus ermöglicht die Bildung von interaktiven Abläufen, die mehrere Eintrittspunkte zur Wechselwirkung mit dem Ablauf aufweisen. Dieses Verhalten wird durch verschiedene Aktivitäten wie etwa Web-Formulare, die als Teil der Mashup-Erzeugung mit der Geschäfts-Mashup-Plattform (BMP) entworfen sind, vorteilhaft genutzt.
Ein Konzept von Bite ist das erweiterbare Design, das es der Entwickler-Gemeinschaft ermöglicht, in erstklassiger Weise eine zusätzliche Funktionalität bereitzustellen, indem Bite-Erweiterungsaktivitäten erzeugt werden und diese mit der Bite-Maschine registriert werden. Dieses Design ermöglicht, die Sprache und ihre Laufzeit sehr klein zu halten und ermöglicht Entwicklern, andere erforderliche Aktivitäten als Erweiterungen zu implementieren. Erweiterungsaktivitäten können unter Verwendung von Java oder jeder Scriptsprache, die durch Java Scripting API (z. B. Groovy, Ruby, Python usw.) unterstützt wird, erzeugt werden.
4 zeigt den (gekürzten) Bite-Code für das Einstellungsbeispiel von 3. Jedes Mashup weist ein Wurzelelement, das als Prozess bezeichnet wird, auf (Zeile 1). Eine neue Ablauf-Instanz wird erzeugt durch Senden einer HTTP-POST-Anforderung an die relative URL/hiring des anfänglichen receivePOST (Zeile 2). Die Daten, die der POST-Anforderung zugehörig sind, stehen in der Variable hrInput implizit zur Verfügung, die an alle abhängigen Aktivitäten ausgegeben wird. In diesem Fall enthält die Variable eine Abbildung aller POST-Parameter. Nach Beendigung der hrInput-Aktivität wird die gcal-Aktivität aktiviert (Zeilen 5 bis 10). Übergänge zwischen Aktivitäten werden durch das Steuerelement ausgedrückt (Zeile 6). Von den Zeilen 12 bis 15 antwortet das Mashup auf das anfängliche HTTP-POST von dem Einstellungsmanager, das ihn informiert, dass er eine e-Mail mit den ausgewählten Gesprächsdaten erhalten wird. Die Gesprächsplanung wird in den Zeilen 18 bis 23 ausgeführt, indem ein HTTP-POST-Ruf an das Gesprächsplanungssystem ausgegeben wird. Dann werden die anderen verbleibenden Schritte ausgeführt, z. B. das Senden einer e-Mail unter Verwendung der sendMail-Aktivität und das Vorbereiten des Kandidatenformulars unter Verwendung der Formular-Aktivität, die beide als Bite-Erweiterungsaktivitäten implementiert sind (zur Einfachheit in der Auflistung nicht gezeigt). Schließlich lädt die Erweiterungsaktivität shareFile (Zeilen 28 bis 37) die gesammelten Kandidatendaten zu LotosLive hoch.
Der abgehende HTTP-GET- und POST-Ruf (gcal und scheduleInterview) und die shareFile-Aktivität erfordern verschiedene Sicherheitsberechtigungen, die zum erfolgreichen Ausführen des Mashup erforderlich sind.
5 ist ein Überblick der Sicherheitslösungen, die die beispielhafte Ausführungsform der vorliegenden Erfindung wie in 3 beschrieben implementiert. Wie im Folgenden genau beschrieben wird, ermöglicht der SAS, dass mehrere Benutzer mit dem Mashup zusammenwirken und das Mashup im Auftrag jedes Benutzers auf die Dienste zugreift.
Um Sicherheit in einer Firmen-Mashup-Plattform zu schaffen, wird das Folgende adressiert: (i) Authentifizierung von Benutzern bei Fremddiensten (d. h. Verifizieren der von einem Benutzer beanspruchten Identität) und (ii) Authentifizieren in dem Sinn, dass der Benutzer die Bite-Maschine authentifizieren muss, um den Task im Auftrag des Benutzers auszuführen. Außerdem werden zwei Aspekte unterschieden. Erstens kann Sicherheit auf einer Sprachebene adressiert werden, um Sicherheitsbedenken in die Bite-Sprache zu integrieren. Es kann vorteilhaft sein, die Spracherweiterungen minimal zu halten und eine Erweiterungsunterstützung für verschiedene Authentifizierungsprotokolle in einer nahtlosen, auf den Benutzer konzentrierten Weise bereitzustellen. Zweitens ist ein erweiterungsfähiger Mechanismus nützlich, um die Authentifizierung und Berechtigung von vertrauenswürdigen Diensten, die unterschiedliche Authentifizierungsprotokolle aufweisen, zu realisieren. Dieser Prozess wird durch einen sicheren Authentifizierungsdienst (SAS), der eine OAuth-Schnittstelle aufweist, transparent gehandhabt.
In 5 ist die grundlegende Übersicht über die Sicherheitslösung dargestellt. Die Bite-Maschine, die einen ausführbaren Ablauf enthält, ist links gezeigt (wobei das veranschaulichende Beispiel von 3 neu zusammengestellt ist). Die weißen Dienste bilden Dienste, die keine Authentifizierung benötigen, die grauen erfordern eine Authentifizierung. In der Mitte befindet sich SAS, der in einem sicheren und zuverlässigen Bereich im Firmennetzwerk betrieben werden muss, da er während der Ausführung eines Ablaufs Berechtigungsnachweise verwaltet. Rechts sind Fremddienste dargestellt, die während der Ausführung aufgerufen werden. Es ist sinnvoll, den SAS an einem zuverlässigen Ort zu platzieren. Einige Optionen enthalten entweder einen Fremdanbieter oder einen SAS bei jedem Dienstanbieter. Da der Schwerpunkt auf Firmen-Mashups liegt, ist es denkbar, dass der SAS einen Dienst darstellt, der durch die Firma selbst angeboten wird, wodurch Vertraulichkeitsprobleme zwischen Benutzern und der Proxy-Infrastruktur weniger Schwierigkeiten bereiten.
Wenn der Benutzer die Ausführung des Ablaufs durch die Verwendung der HTTP-POST-Anforderung in dem Web-Formular (oder von einer anderen Anwendung) auslöst, wird das Mashup ausgeführt und sobald es den ersten ”gesicherten” Fremddienst (die gcal-Aktivität von 4) erreicht, wird die Bite-Maschine einen Sicherheits-Handler verwenden, damit sich der Benutzer bei dem Zieldienst authentifizieren kann. Der Handler bewirkt dies durch Zusammenwirken mit dem SAS. Der SAS ermöglicht das Einschalten in mehrere unterschiedliche Sicherheitsmodule wie etwa OAuth, http-Basic-Authentication und AppID, um eine Unterstützung für verschiedene Sicherheitsmechanismen bei dem Zieldienst bereitzustellen. Bei der Prozedur zum Ausführen von Berechtigung und Authentifizierung gibt es zwei Fälle: synchrone Authentifizierung und asynchrone Authentifizierung.
Synchrone Authentifizierung: In diesem Fall wirkt der Benutzer bereits über eine Web-Anwendung mit dem Ablauf zusammen und kann somit einfach zu dem SAS umgeleitet werden, um die Authentifizierung beim Zieldienst auszuführen. In dem Ablauf bedeutet das, dass receiveGET|POST bearbeitet wurde, ohne jedoch eine entsprechende replyGET|POST-Aktivität zu erreichen. Das ist z. B. der Fall für die gcal-Aktivität von 4 (Zeilen 5 bis 10), die sich zwischen einem receivePOST und einem replyPOST befindet.
Asynchrone Authentifizierung: In diesem Fall ist der Ablauf bereits zum Benutzer zurückgekehrt, indem eine replyGET|POST-Aktivität ausgeführt wurde. Alternativ wird eine Aktivität mit der Bezeichnung receive-replyGET|POST verwendet, um eine ankommende Anforderung zu empfangen und sofort zu beantworten. Deswegen wirkt der Benutzer nicht länger mit dem Ablauf zusammen und es gibt keine Verbindung, die zu dem SAS umgeleitet werden kann. Zum Beispiel alle Aktivitäten von 4 nach Zeile 18 (und zwar scheduleInterview, emailCandidate, collectCandidateData und storeApplication). Eine mögliche Lösung besteht darin, den Benutzer unter Verwendung asynchroner Techniken zu kontaktieren, um ihn aufzufordern, sich bei dem Fremddienst zu authentifizieren. Das kann durch e-Mail und Nachrichtensofortversand (instant messaging) erreicht werden.
Die Kommunikation zwischen der Bite-Maschine und dem SAS verwendet eine geringfügig erweiterte Version des OAuth-Protokolls, um die Handhabung von Authentifizierung und Berechtigung zwischen Web-Anwendungen (in unserem Fall die Bite-Maschine und der SAS) nahtlos zu implementieren.
6 ist ein beispielhaftes Ablaufmodell von dem beispielhaften Szenario in 3 eines beispielhaften Sicherheitserweiterungselements. Um Sicherheit in Bite zu ermöglichen, kann die Sprache erweitert werden, um die Sicherheitsanforderungen wie etwa Authentifizierung und Berechtigung zu umfassen. Ein Ziel kann darin bestehen, derartige Spracherweiterungen minimal zu halten. Authentifizierung und Berechtigung von Benutzern, die einen Mashup ausführen möchten, wird als Eingangssicherheit bezeichnet. Das heißt Eingangssicherheit ist der Fall, bei dem eine Nachricht zu dem Mashup gesendet wird (d. h. das Mashup ist in diesem Fall der sichere Dienst). Eingangssicherheit wird auf einer Laufzeitebene hergestellt, wobei sich der Benutzer unter Verwendung von OpenID oder ähnlichen Protokollen bei einem externen Authentifizierungsdienst authentifiziert und der authentifizierte Benutzer in den Prozesskontext eingeführt wird, wo er bei Empfangsaktivitäten (receiveGET-POST) gegen Benutzereinschränkungen geprüft werden kann. Wenn der Benutzer auf die Empfangsdaten zugreifen darf, wird die Aktivität aktiviert, speichert die Nachricht und die Benutzerinformationen in den geeigneten Variablen und wird beendet. Andernfalls wird ein Fehler an den Benutzer zurück gesendet und die Empfangsaktivität wird nicht aktiviert. Es wird angemerkt, dass möglicherweise vorhandene Benutzerinformationen für alle Aktivitäten, die mit Benutzern zusammenwirken, zur Laufzeit in einer impliziten Variablen [activity name] User gespeichert werden. Somit können nachfolgende Aktivitäten diese Variable verwenden, um auf einen bestimmten Benutzer Bezug zu nehmen.
Um die Sicherheitscharakteristiken und Anforderungen einer Aktivität zu definieren, wird ein Sicherheitserweiterungselement bereitgestellt und für alle abgehenden Kommunikationsaktivitäten wie etwa GET, POST, PUT, DELETE und alle Erweiterungsaktivitäten, die Kundenverhalten implementieren, das ebenfalls eine Authentifizierung erfordern kann, optional gemacht.
4 weist drei Sicherheitselemente (Zeilen 9, 22 und 31 bis 36) in dem Ablauf auf. In 6 ist die Sicherheitselementsyntax dargestellt.
Attributbeschreibung: Die Attribute, die für das Sicherheitselement verfügbar sind, lauten:
authtype: Spezifiziert den Authentifizierungstyp zum Authentifizieren eines Benutzers beim Zieldienst. OAuth, http-Basic-Authentication und kundenspezifische Anwendungskennungen, die durch verschiedene Dienstanbieter in der Form von einzelnen oder mehreren GET- oder POST-Parametern häufig verwendet werden, werden unterstützt. Die Handhabung dieser Authentifizierungstypen wird durch den sicheren Authentifizierungsdienst (SAS) transparent unterstützt.
user: Definiert den Namen des Benutzers (als ein String oder ein Ausdruck), in dessen Auftrag ein bestimmter Dienst ausgeführt wird. Dieses Benutzerattribut ist insbesondere für Erweiterungsaktivitäten relevant, die die Semantik ”on behalf of” unterstützen. Zum Beispiel verwendet der Bewerbungsablauf von 4 LotusLive, um Dateien hochzuladen und gemeinsam zu nutzen. Diese Anwendung unterstützt die Semantik ”on behalf of”, indem explizit definiert wird, wer ein Dokument hochgeladen hat, was durch das Benutzerattribut in dem Bite-Ablauf angegeben wird (dieser Benutzername wird dann in dem File-Sharing-Dienst von LotusLive als der Besitzer des hochgeladenen Dokuments verwendet).
roles: Definiert Rollen, die ein Benutzer haben kann, in der Form von durch Kommas getrennten Strings. Wenn eine Rolle verwendet wird, können Rollendefinitionen zur Laufzeit bereitgestellt werden.
notification: Die Benachrichtigung definiert, wie ein Benutzer benachrichtigt werden sollte, dass ein Dienst eine Authentifizierung erfordert. Bei einer synchronen Authentifizierung kann http verwendet werden, um zum SAS umzuleiten, damit Authentifizierung und Berechtigung angefordert werden. Im asynchronen Fall muss der Ablauf zum Benutzer zurückkehren, um eine Authentifizierung anzufordern. Das kann erfolgen durch Blockierung der Aktivität, die Sicherheit erfordert, Senden einer e-Mail an den Benutzer (Attributwert e-Mail) oder das Verwenden eines Nachrichtensofortversands (Attributwert Sametime), die ihn zum SAS führen, und das Wiederaufnehmen der Aktivität, nachdem Authentifizierung/Berechtigung beendet wurden. Ein Lösungsansatz verwendet Lotus Sametime; andere Protokolle können in einfacher Weise hinzugefügt werden.
notificationReceiver: Dieses Attribut wird nur dann benötigt, wenn der Benachrichtigungstyp e-Mail oder Sametime verwendet wird, da es dann erforderlich ist, die Kontaktdetails zu haben (z. B. e-Mail-Adresse oder Sametime-Kontakt). Bei http ist das nicht erforderlich, da der Benutzer in dem Browser noch mit dem Ablauf zusammenwirkt und somit zu dem SAS umgeleitet wird, um die Authentifizierung auszuführen.
scope: Der Umfang definiert, ob Sicherheitsberechtigungen einer Aktivität zu den anderen Aktivitäten zur Wiederverwendung verbreitet werden. Wenn der Attributwert Ablauf ist, werden Berechtigungen verbreitet, wodurch wiederholte Anmeldungen vermieden werden, indem Berechtigungen bei einem Dienst wieder verwendet werden, der in einem Ablauf für den gleichen Benutzer mehrmals aufgerufen wird. Bei einem Attributwert Aktivität werden die Berechtigungen nicht verbreitet.
Die Wirkung der Sicherheitselemente auf die Ausführungssemantik der Bite-Sprache ist folgendermaßen: Wenn eine Aktivität, die ein Sicherheitselement aufweist, in einem Ablauf erreicht wird, werden die Werte der Attribute des Sicherheitselements bewertet und in einem Sicherheitskontext gespeichert, wobei dieser in dem Prozesskontext gespeichert wird, der den Zustand der Ausführung für die Ablaufinstanz hält. Diese Informationen werden verwendet, um einen entsprechenden Sicherheits-Handler in einem Handler-Register nachzuschlagen. Der Sicherheitskontext und die Nachrichtennutzlast werden diesem Handler bereitgestellt, der mit dem SAS zusammenwirkt, um die erforderliche Authentifizierung und Berechtigung bereitzustellen. Wenn keine Berechtigungen zur Verfügung stehen, kontaktiert der Handler den Benutzer, der sie an den SAS sendet. Der Handler bewirkt dann einen sicheren Anruf und gibt das Ergebnis an die Aktivitätsimplementierung zurück, die es wiederum in seiner Ausgabevariable speichert. Wenn der Attributwert scope auf activity gesetzt ist, kontaktiert der Sicherheits-Handler den SAS über seine OAuth-Schnittstelle, um mit der erforderlichen Sicherheitshandhabung fortzufahren, und die OAuth-Verbindungs-Token werden nach der Authentifizierung zerstört. Wenn er auf workflow gesetzt ist, werden die OAuth-Token in dem Prozesskontext gespeichert und können wiederverwendet werden, falls der gleiche Dienst in dem Ablauf für denselben Benutzer erneut aufgerufen wird. Die Wiederverwendung der gleichen OAuth-Token zum Verbinden mit dem SAS ermöglicht festzustellen, ob sich der Benutzer zuvor für Bite authentifiziert hat und berechtigt ist, um in seinem Auftrag einen vorgegebenen Fremddienst aufzurufen.
Während der asynchrone Fall keine weiteren Auswirkungen auf die Ablaufsemantik hat, ist der synchrone Fall (http) stärker involviert, denn dann, wenn keine Berechtigungsnachweise verfügbar sind, muss er eine der offenen Verbindungen der Ablaufinstanz wieder verwenden, um den Benutzer zu kontaktieren, ihn zu dem SAS und dann zurück zum Ablauf umzulenken. Bite ermöglicht, dass gleichzeitig mehrere Empfangsaktivitäten offen sind (d. h. die noch nicht beantwortet wurden). Deswegen muss die richtige offene Verbindung identifiziert werden. Dazu werden offene Empfangsaktivitäten in der Ablaufinstanz im Hinblick auf einen Variablenwert ”User” geprüft, der mit demjenigen in dem Sicherheitselement, das behandelt wird, übereinstimmt. Der ”Antwortstatus” einer übereinstimmenden Empfangsaktivität wird auf ”auf Umleitung wartend” gesetzt und für sie wird ein Schlüssel erzeugt, mit dem die Umleitung von dem SAS zurück zum Ablauf in Übereinstimmung gebracht werden kann. Eine Antwort wird zu der offenen Verbindung der Empfangseinrichtung gesendet, die den Benutzer zu dem SAS umleitet. Nachdem der Benutzer die Arbeit mit dem SAS abgeschlossen hat, sendet ihn eine clientseitige Umleitung zurück zum Ablauf. Außerdem wird die übereinstimmende Empfangsaktivitätsinstanz unter Verwendung des Schlüssels gefunden und ihr Antwortstatus wird auf ”offen” zurückgesetzt.
Wenn unter offenen Empfangsvorgängen (receives) keine Übereinstimmung gefunden wird, werden ”auf Antwort wartende” Empfangsvorgänge geprüft, so dass sie schließlich ”offen” werden und zu diesem Zeitpunkt verwendet werden können. Wenn keine Übereinstimmung unter Empfangsvorgängen, die offen sind oder auf Umleitung warten, gefunden wird, wird der Benutzer kontaktiert wie im asynchronen Fall, wenn Kontaktinformationen in der Definition des Sicherheitselements bereitgestellt werden. Andernfalls wird ein Fehler ausgegeben.
Eine Antwort-Aktivität für einen Empfangsvorgang, der eine ”Umleitung erwartet”, muss abwarten, bevor sie ihre Antwort senden kann, bis der Antwortstatus des Empfangsvorgangs wieder ”offen” lautet und keine andere Sicherheitsumleitungen für diesen Empfangsvorgang anhängig sind.
Der sichere Authentifizierungsdienst (SAS) ist verantwortlich für die Bereitstellung eines Proxy, der verschiedene Authentifizierungstypen von unterschiedlichen webbasierten Diensten wie z. B. RESTful transparent handhaben kann. Deswegen unterstützt der SAS unterschiedliche Sicherheitsmechanismen und stellt sich dar unter Verwendung einer OAuth-Schnittstelle, eines populären Protokolls zum Verwalten von Authentifizierung und Berechtigung zwischen webbasierten APIs. Die Spezifikation definiert ihn folgendermaßen: ”OAuth-Protokoll ermöglicht Webseiten oder Anwendungen (Verbrauchern), von einem Web-Dienst (Dienstanbieter) über eine API auf geschützte Ressourcen zuzugreifen, ohne zu erfordern, dass Benutzer ihre Dienstanbieter-Berechtigungsnachweise den Verbrauchern offenbaren.” OAuth weist zwei Vorteile auf für die Verwendung als das Protokoll zum Datenaustausch mit dem SAS: SAS ist ein wohlverstandenes und immer populäreres Protokoll für webbasierte Anwendungen und implementiert eine nahtlose Möglichkeit der Handhabung von Authentifizierung und Berechtigung zwischen einem Verbraucher und einem Anbieter. Der Verbraucher ist in unserem Szenario die Bite-Maschine und der Anbieter ist der SAS selbst. Ein OAuth-Anbieter muss drei unterschiedliche Anforderungs-URLs bereitstellen: (1) eine Anforderungs-Token-URL (relative URL/request token); (2) eine Benutzerauthentifizierungs-URL (/authorize); und (3) eine Zugriffs-Token-URL (/access token). Eine typische Authentifizierung und Berechtigung wird folgendermaßen gehandhabt: Zuerst fordert ein Verbraucher einen Anforderungs-Token unter Verwendung der Anforderungs-Token-URL (1) durch Senden mehrerer OAuth-spezifischer Parameter, wie etwa ein im Voraus verhandelter Verbraucherschlüssel, um die Verbraucheranwendung, Zeitstempel, Einmalschlüssel, Signatur usw. zu identifizieren. Wenn alle Parameter korrekt und verifizierbar sind, gibt der Dienstanbieter einen nicht authentifizierten Anforderungs-Token aus. Wenn der Anforderungs-Token vom Verbraucher empfangen wird, kann der Browser des Benutzers zu dem Dienstanbieter umgelenkt werden, um Authentifizierung und Berechtigung zu erhalten. Diese Authentifizierung stellt sicher, dass der Benutzer, der hinter dem Browser steht, ausdrücklich gewährleistet, dass die Web-Anwendung des Verbrauchers in seinem Auftrag auf die Ressourcen des Dienstanbieters zugreifen darf. Nachdem die Authentifizierung ausgeführt wurde, kann der Dienstanbieter den Benutzer wieder zur Verbraucheranwendung umlenken (unter Verwendung einer Rückruf-URL). Schließlich muss der Verbraucher den Anforderungs-Token beim Dienstanbieter gegen einen Zugriffs-Token austauschen. Das wird typischerweise gewährt, wenn der Benutzer die Authentifizierung und Berechtigung im vorhergehenden Schritt erfolgreich ausgeführt hat. Dieser Zugriffs-Token ist einer der OAuth-Parameter, der (unter anderen wie etwa Verbraucherschlüssel, Zeitstempel, Signatur usw.) mit jeder weiteren Anforderung zu dem geschützten Dienst gesendet werden kann.
Die transparente Unterstützung einer sicheren Authentifizierung und Berechtigung von unterschiedlichen Fremddiensten über die OAuth-Schnittstelle des SAS erfordert eine Erweiterung des OAuth-Protokolls. Das ermöglicht, dass der SAS als ein ”sicherer Proxy” für verschiedene andere Authentifizierungsprotokolle wirkt. Dazu benötigt der SAS wenigstens die URL und den Authentifizierungstyp des Zieldienstes. Da diese Informationen in der Aktivitätsbeschreibung und der Sicherheitserweiterung in einem Bite-Ablauf zur Verfügung stehen (z. B. 4, Zeilen 18 bis 23), müssen sie lediglich an den SAS gesendet werden, um eine transparente Authentifizierung des Fremddienstes zu ermöglichen. Somit werden mehrere Anforderungsparameter hinzugefügt, wenn die Bite-Maschine wie nachfolgend erläutert beim SAS einen Anforderungs-Token anfordert.
HTTP-Basic-Authentication wird in der Praxis weit verbreitet verwendet, obwohl sie nicht sehr sicher ist, es sei denn, SSL wird verwendet. Sie kann in Bite festgelegt werden, indem der Authentifizierungstyp authtype auf http basic (siehe 4, Zeile 22) gesetzt wird. Während der Laufzeit kontaktiert die Bite-Maschine den SAS unter Anforderung eines Anforderungs-Token, indem die folgende erweiterte OAuth-Anforderung gesendet wird:
http://sas.watson.ibm.com/request_token?oauth_consumer_key=bite_app&oauth_timestamp=...&oauth_signature=...&oauth_...=...&x-oauth_serviceurl=http://internal.acme.com/interview/schedule&x-oauth_authtype=http_basic
Die Parameter x-oauth_serviceurl und x-oauth_authtype geben die Ziel-URL des sicheren Fremddienstes und seinen Authentifizierungstyp von der Aktivität scheduleInterview von 4 an (die Erweiterung trägt den Präfix x-, da dieser ebenfalls ein übliches Muster für HTTP-Vorsatz-Erweiterungen ist). Bei einer synchronen Authentifizierung wird der Benutzer zu der SAS-Web-Schnittstelle umgeleitet, andernfalls (im asynchronen Fall) empfängt die Benutzerkennung, die in dem Attribut notificationReceiver spezifiziert ist, einen Link, der für die Authentifizierung verwendet wird (im Wesentlichen der gleiche, auf den Bite im synchronen Fall umleitet).
Diese beiden Erweiterungsattribute werden durch den SAS verwendet, um einen abgehenden Anruf an die Ziel-URL in einem iframe zu bewirken. Er fordert den Benutzer auf, die Berechtigungsnachweise des Zieldienstes zu bestätigen. Wenn die Authentifizierung erfolgreich ist, wird der HTTP-Authentifizierungsvorsatz des Zieldienstes durch den Proxying-Mechanismus des SAS abgehört. Ein einfaches Proxy-Servlet (/proxy) wird verwendet, um beim SAS das transparente Proxying zu erreichen. Die Antwort des Zieldienstes wird beim SAS in eine Warteschlange eingereiht, andernfalls würde der Dienst zweimal aufgerufen: einmal für die Authentifizierung und einmal für den Aufruf des ursprünglichen Dienstes. Wenn der erste ”reale” Dienstaufruf ausgeführt wird, kehrt der SAS während des Authentifizierungsprozesses zu der in der Warteschlange befindlichen Antwort zurück.
Die Unterstützung von kundenspezifischen Anwendungskennungen erfordert das Hinzufügen eines weiteren OAuth-Erweiterungsparameters mit der Bezeichnung x-oauth_appid_mapping, der Einzelheiten codiert, wie Anwendungskennungen von dem Benutzer in einem dynamisch gebildeten Web-Formular beim SAS abgefragt werden und wie diese Daten zu dem Zieldienst gesendet werden (z. B. in dem HTTP-Vorsatz oder als GET- oder POST-Parameter). Deswegen definiert das Sicherheitserweiterungselement in dem Bite-Ablauf ein Abbildungselement (4, Zeilen 31 bis 36). Diese Abbildung stellt insbesondere fest, dass der Zieldienst zwei Parameter par und key für eine erfolgreiche Authentifizierung aufweist, die als HTTP-POST-Parameter angefügt werden müssen (da diese Erweiterungsaktivität intern POST verwendet). Zusätzlich definiert jedes Element ein Bezeichnungsattribut als eine Bezeichnung für das HMTL-Eingabeelement in das dynamisch gebildete Authentifizierungsformular.
Beim Ausführen eines derartigen auf einer Anwendungskennung basierenden Dienstes serialisiert die Bite-Maschine die Bite-XML-Abbildung in ein einfaches textbasiertes Formular, das unter Verwendung der oben erwähnten OAuth-Erweiterungen zum SAS übertragen wird. Dann wird das dynamisch gebildete Authentifizierungsformular gezeigt, um eine Bestätigung für die Anwendungskennungen zu fordern.
Die Unterstützung für OAuth wird ebenfalls durch den SAS transparent unterstützt. In diesem Fall fügt der SAS lediglich eine weitere Ebene der Umleitung zwischen Bite und dem Zieldienstanbieter hinzu, ohne Informationen zu speichern. Es wäre möglich, einen kundenspezifischen Sicherheits-Handler zu implementieren, um OAuth-basierte Dienste direkt zu verbrauchen (da Bite bereits ein OAuth-Verbraucher für den SAS ist). Das Durchlaufen des SAS beim Verbrauchen von OAuth-basierten Diensten hat jedoch den Vorteil der transparenten Handhabung mehrerer Sicherheitsmechanismen für die Bite-Maschine.
Bite und der SAS wurden in Java 1.6 implementiert. Bite kann entweder auf einem Servlet-Container oder einem WebShpere-sMash-Server betrieben werden. Die SAS-Implementierung basiert auf der Java-OAuth-Implementierung von Google, die mehrere Servlets für die verschiedenen Endpunkte (Anforderungs-Token, Zugangs-Token usw.) bereitstellt. Diese Servlets wurden erweitert, damit sie die oben erwähnten Sicherheitsprotokolle transparent unterstützen. Die Bite-Maschine implementiert den OAuth-Client durch die Verwendung eines spezifischen Sicherheits-Handlers beim Aufrufen von Diensten aus einer Aktivität mit einem Sicherheitselement (SASSecurityHandler). Alle anderen Aufrufe verwenden einen NullSecurityHandler, der den SAS nicht einbindet.
7A ist eine beispielhafte Webseite eines Browsers des Benutzers, wenn zu dem SAS umgeleitet wird, aus dem beispielhaften Szenario von 3. 7B ist eine beispielhafte Authentifizierungs-Webseite eines Browsers des Benutzers aus dem beispielhaften Szenario von 3. Die 7A und 7B veranschaulichen die Web-Schnittstelle des SAS für Authentifizierung und Berechtigung für die Aktivität shareFile von 4 (Zeilen 28 bis 37), die kundenspezifische Anwendungskennungen als den ”Sicherheits”-Mechanismus verwendet. 7A zeigt das dynamisch gebildete Authentifizierungsformular basierend auf der Spezifikation in Bite. Wenn der Browser des Benutzers zu dem SAS umgeleitet wird, sieht der Benutzer die Webseite in der gezeigten Weise. Durch Klicken auf den Link öffnet sich das Authentifizierungs-Eingabefeld und der Benutzer gibt die Berechtigungsnachweise ein. Nach Übertragen der Berechtigungsnachweise muss der Benutzer Bite ausdrücklich authentifizieren, den Dienst in seinem Auftrag aufzurufen (7B). Wenn der Benutzer Bite authentifiziert, fährt der Ablauf mit seiner Ausführung fort und der Benutzer wird (im synchronen Fall) zurück zu der Ablauf-Anwendung umgeleitet, andernfalls wird ein Fehler ausgegeben. Die gleiche Benutzererfahrung steht für HTTP-Basic-Authentication zur Verfügung, das Dialog-Eingabefeld wird jedoch nicht dynamisch sondern browserspezifisch gebildet.
Der vorgeschlagene Ansatz, der auf dem SAS basiert, unterstützt wirksam sowohl Authentifizierung als auch Berechtigung von Fremddiensten ohne die Notwendigkeit, die Berechtigungsnachweise für Verbraucheranwendungen zu offenbaren (wie in unserem Fall Bite).
Durch einen Fachmann auf dem Gebiet wird anerkannt, dass Aspekte der Erfindung als ein System, Verfahren oder Computerprogrammprodukt ausgeführt werden können. Dementsprechend können Aspekte der Erfindung die Form einer vollständigen Hardware-Ausführungsform, einer vollständigen Software-Ausführungsform (die Firmware, residente Software, Mikrocode usw. enthält) oder einer Ausführungsform, die Software- und Hardware-Aspekte kombiniert, annehmen, die alle hier im Allgemeinen als ”Schaltung”, ”Modul” oder ”System” bezeichnet werden können. Des Weiteren können Aspekte der Erfindung die Form eines Computerprogrammprodukts annehmen, das in einem oder mehreren computerlesbaren Medien ausgeführt ist, die computerlesbaren Programmcode aufweisen, der darin ausgeführt wird.
Jede Kombination aus einem oder mehreren computerlesbaren Medien kann verwendet werden. Das computerlesbare Medium kann ein computerlesbares Signalmedium oder ein computerlesbares Speichermedium sein. Ein computerlesbares Speichermedium kann z. B. ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitersystem, eine Vorrichtung oder Einheit oder jede geeignete Kombination des Vorhergehenden sein, wobei keine Beschränkung darauf besteht. Zu spezifischeren Beispielen (eine nicht erschöpfende Liste) des computerlesbaren Speichermediums würde Folgendes gehören: eine elektrische Verbindung mit einer oder mehreren Leitungen, eine tragbare Computerdiskette, eine Festplatte, ein Arbeitsspeicher (RAM), ein Festwertspeicher (ROM), ein löschbarer programmierbarer Festwertspeicher (EPROM oder Flash-Speicher), eine Lichtleitfaser, ein tragbarer Compactdisk-Festwertspeicher (CD-ROM), eine optische Speichereinheit, eine magnetische Speichereinheit oder jede geeignete Kombination aus dem Vorhergehenden. Im Kontext dieses Dokuments kann ein computerlesbares Speichermedium jedes materielle Medium sein, das ein Programm zur Verwendung durch oder in Verbindung mit einem System, einer Vorrichtung oder einer Einheit zur Befehlsausführung enthalten oder speichern kann.
Ein computerlesbares Signalmedium kann ein verbreitetes Datensignal einschließen, wobei computerlesbarer Programmcode darin ausgeführt wird, z. B. im Basisband oder als Teil einer Trägerwelle. Ein derartiges verbreitetes Signal kann die Form jeder von einer Vielzahl von Formen annehmen, zu denen eine elektromagnetische Form, eine optische Form oder jede geeignete Kombination hiervon gehören, die jedoch nicht darauf beschränkt sind. Ein computerlesbares Signalmedium kann jedes computerlesbare Medium sein, das kein computerlesbares Speichermedium ist und ein Programm zur Verwendung durch oder in Verbindung mit einem System, einer Vorrichtung oder einer Einheit zur Befehlsausführung kommunizieren, verbreiten oder transportieren kann.
Programmcode, der auf einem computerlesbaren Medium ausgeführt wird, kann unter Verwendung jedes geeigneten Mediums übertragen werden, zu dem drahtlose, leitungsgestützte Medien, ein Lichtleitfaserkabel, HF usw. oder jede geeignete Kombination des Vorhergehenden gehören, wobei keine Beschränkung darauf besteht.
Computerprogrammcode zum Ausführen von Operationen für Aspekte der vorliegenden Erfindung kann in jeder Kombination aus einer oder mehreren Programmiersprachen geschrieben sein, dazu gehören eine objektorientierte Programmiersprache wie etwa Java, Smalltalk, C++ oder dergleichen und herkömmliche prozedurale Programmiersprachen wie die Programmiersprache ”C” oder ähnliche Programmiersprachen. Der Programmcode kann vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers als ein selbstständiges Softwarepaket, teilweise auf dem Computer des Benutzers und teilweise auf einem fernen Computer oder vollständig auf dem fernen Computer oder Server ausgeführt werden. In dem zuletzt genannten Szenario kann der ferne Computer mit dem Computer des Benutzers über einen Typ von Netzwerk verbunden sein, wozu ein Lokalbereichs-Netzwerk (LAN) oder ein Weitbereichs-Netzwerk (WAN) gehören, oder die Verbindung kann mit einem externen Computer (z. B. über das Internet unter Verwendung eines Internetdienstanbieters) erfolgen.
Aspekte der Erfindung werden im Folgenden unter Bezugnahme auf Ablaufplan-Darstellungen und/oder Blockschaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es sollte klar sein, dass jeder Block von Ablaufplan-Darstellungen und/oder Blockschaubildern und Kombinationen von Blöcken in den Ablaufplan-Darstellungen und/oder Blockschaubildern durch Computerprogrammbefehle implementiert werden können. Diese Computerprogrammbefehle können an einen Prozessor eines Mehrzweck-Computers, eines speziellen Computers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, so dass die Befehle, die über den Prozessor des Computers oder der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführt werden, Mittel zum Implementieren der Funktionen/Wirkungen erzeugen, die in dem Block oder den Blöcken des Ablaufplans und/oder des Blockschaubilds spezifiziert sind.
Diese Computerprogrammbefehle können außerdem in einem computerlesbaren Medium gespeichert sein, das einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder andere Einheiten anweisen kann, in einer bestimmten Weise zu funktionieren, so dass die in dem computerlesbaren Medium gespeicherten Befehle einen Herstellungsgegenstand erzeugen, einschließlich Befehle, die die Funktion/Wirkung implementieren, die in dem Block oder den Blöcken des Ablaufplans und/oder des Blockschaubilds spezifiziert sind.
Die Computerprogrammbefehle können außerdem auf einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder andere Einheiten geladen werden, um eine Reihe von Operationsschritten zu bewirken, die auf dem Computer, der anderen programmierbaren Datenverarbeitungsvorrichtung oder anderen Einheiten ausgeführt werden, um einen computerimplementierten Prozess zu erzeugen, so dass die Befehle, die auf dem Computer oder der anderen programmierbaren Vorrichtung ausgeführt werden, Prozesse zum Implementieren der Funktionen/Wirkungen, die in dem Block oder den Blöcken des Ablaufplans und/oder des Blockschaubilds spezifiziert sind, bereitzustellen.
Der Ablaufplan und die Blockschaubilder in den Figuren veranschaulichen die Architektur, Funktionalität und Operation von möglichen Implementierungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. In dieser Hinsicht kann jeder Block in dem Ablaufplan oder den Blockschaubildern ein Modul, Segment oder Abschnitt von Code repräsentieren, der einen oder mehrere Befehle zum Implementieren der spezifizierten logischen Funktion(en) umfasst. Es sollte außerdem angemerkt werden, dass in einigen alternativen Implementierungen die in dem Block angegebenen Funktionen nicht in der in den Figuren angegebenen Reihenfolge auftreten können. Zum Beispiel können zwei Blöcke, die nacheinander gezeigt sind, tatsächlich im Wesentlichen gleichzeitig ausgeführt werden oder die Blöcke können gelegentlich in Abhängigkeit von der beteiligten Funktionalität in umgekehrter Reihenfolge ausgeführt werden. Es wird außerdem angemerkt, dass jeder Block der Blockschaubilder und/oder Ablaufplandarstellung und Kombinationen von Blöcken in den Blockschaubildern und/oder der Ablaufplandarstellung durch Systeme auf der Grundlage von spezieller Hardware, die die spezifizierten Funktionen oder Wirkungen ausführen, oder Kombinationen aus spezieller Hardware und Computerbefehlen implementiert werden.
Während die bevorzugten Ausführungsformen der Erfindung beschrieben wurden, sollte klar sein, dass ein Fachmann sowohl jetzt als auch zukünftig verschiedene Verbesserungen und Erweiterungen machen kann, die in den Umfang der nachfolgenden Ansprüche fallen. Deswegen sollten die Ansprüche so aufgefasst werden, dass sie den geeigneten Schutz für die oben beschriebene Erfindung aufrechterhalten.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

Leser auf Francisco Curbera, Matthew Duftler, Rania Khalaf, Douglas Lovell, Bite: Workflow Composition for the Web, International Conference an Service Oriented Computing (ICSOC 2007), Springer LNCS, Vienna, Austria, Sept. 17–20, 2007 [0021]

Claims

Verfahren zum Zugreifen auf Daten, wobei das Verfahren aufweist: Empfangen eines Ablaufmodells, das in einer Ablaufsprache beschrieben ist und konfiguriert ist, um Sicherheitsanforderungen einer kombinierten Anwendung, die geschützte Daten von zwei oder mehr externen Netzwerkressourcen integriert, zu deklarieren, wobei die kombinierte Anwendung auf wenigstens einem Host-Servercomputer gemäß dem Ablaufmodell ausgeführt wird; und Ausführen eines Authentifizierungsdienstes auf wenigstens einem sicheren Servercomputer, wobei der Authentifizierungsdienst konfiguriert ist, um eine Benutzer-Authentifizierung und -Berechtigung durchzuführen, um auf die geschützten Daten an den externen Netzwerkressourcen im Auftrag der kombinierten Anwendung zuzugreifen.
Verfahren zum Zugreifen auf Daten nach Anspruch 1, wobei der Servercomputer durch eine Entität, der durch den Benutzer vertraut wird, gesteuert wird.
Verfahren zum Zugreifen auf Daten nach Anspruch 1, wobei die Ablaufsprache eine erweiterungsfähige Ablaufsprache ist.
Verfahren zum Zugreifen auf Daten nach Anspruch 1, das ferner das Abrufen von Protokollinformationen über eine der zwei oder mehr externen Netzwerkressourcen aufweist.
Verfahren zum Zugreifen auf Daten nach Anspruch 1, das ferner das Verbinden mit dem Authentifizierungsdienst von der kombinierten Anwendung aufweist.
Verfahren zum Zugreifen auf Daten nach Anspruch 1, das ferner das Verbinden mit einer der zwei oder mehr externen Netzwerkressourcen von dem Authentifizierungsdienst aufweist.
Verfahren zum Zugreifen auf Daten nach Anspruch 1, ferner aufweisend: Erhalten von Benutzer-Berechtigungsnachweisen durch den Authentifizierungsdienst; und Verwenden der Benutzer-Berechtigungsnachweise, um die Benutzer-Authentifizierung und -Berechtigung durchzuführen, um auf die geschützten Daten in den externen Netzwerkressourcen zuzugreifen.
System zum Zugreifen auf Daten, wobei das System aufweist: ein Ablaufmodell, das in einer Ablaufsprache beschrieben ist und konfiguriert ist, um Sicherheitsanforderungen einer kombinierten Anwendung, die geschützte Daten von zwei oder mehr externen Netzwerk Ressourcen integriert, zu deklarieren, wobei die kombinierte Anwendung auf wenigstens einem Host-Servercomputer gemäß der Ablaufsprache ausgeführt wird; und einen Authentifizierungsdienst, der auf wenigstens einem sicheren Servercomputer ausgeführt wird, wobei der Authentifizierungsdienst konfiguriert ist, um eine Benutzer-Authentifizierung und -Berechtigung durchzuführen, um auf die geschützten Daten in den externen Netzwerkressourcen im Auftrag der kombinierten Anwendung zuzugreifen.
System zum Zugreifen auf Daten nach Anspruch 8, wobei Benutzer-Berechtigungsnachweise in dem Authentifizierungsdienst gespeichert werden.
System zum Zugreifen auf Daten nach Anspruch 8, wobei die kombinierte Anwendung ferner aufweist: wenigstens einen Sicherheits-Handler, um mit dem Authentifizierungsdienst Daten auszutauschen, wobei der Sicherheits-Handler konfiguriert ist, um unter Verwendung eines Sicherheitsprotokolls mit dem Authentifizierungsdienst Daten auszutauschen; und eine Ablaufinstanz des Ablaufmodells.
System zum Zugreifen auf Daten nach Anspruch 10, wobei das Sicherheitsprotokoll OAuth ist.
System zum Zugreifen auf Daten nach Anspruch 10, wobei das Sicherheitsprotokoll HTTP-Basic-Authentication ist.
System zum Zugreifen auf Daten nach Anspruch 10, wobei die Ablaufinstanz ihren Ausführungszustand aufrechterhält, wenn die kombinierte Anwendung mit dem Authentifizierungsdienst Daten austauscht.
System zum Zugreifen auf Daten nach Anspruch 10, wobei eine Gruppe von Benutzer-Berechtigungsnachweisen, die über den Authentifizierungsdienst erhalten wird, in dem Sicherheits-Handler zur Verwendung während der Ablaufinstanz gespeichert wird.
Computerprogrammprodukt, aufweisend: ein computerlesbares Speichermedium, das computerlesbaren Programmcode aufweist, der damit ausgeführt wird, wobei der computerlesbare Programmcode konfiguriert ist zum Empfangen eines Ablaufmodells, das in einer Ablaufsprache beschrieben ist und konfiguriert ist, um Sicherheitsanforderungen einer kombinierten Anwendung, die geschützte Daten von zwei oder mehr externen Netzwerkressourcen integriert, zu deklarieren; und Ausgeben einer Anforderung an einen Authentifizierungsdienst, der auf wenigstens einem sicheren Servercomputer ausgeführt wird, um eine Benutzer-Authentifizierung und -Berechtigung durchzuführen, um auf geschützte Daten in den externen Netzwerkressourcen im Auftrag der kombinierten Anwendung gemäß der Ablaufsprache zuzugreifen.
Computerprogrammprodukt nach Anspruch 15, wobei die Anforderung an den Authentifizierungsdienst einen Benutzer von der kombinierten Anwendung zu dem Authentifizierungsdienst umleitet, um die Berechtigungsnachweise anzufordern.
Computerprogrammprodukt nach Anspruch 15, wobei der computerlesbare Programmcode ferner konfiguriert ist, um einen Benutzer über einen asynchronen Nachrichtendienst zu kontaktieren.
Computerprogrammprodukt nach Anspruch 17, wobei der asynchrone Nachrichtendienst elektronische Mail ist.
Computerprogrammprodukt nach Anspruch 17, wobei der asynchrone Nachrichtendienst ein Nachrichtensofortversand ist.
Computerprogrammprodukt nach Anspruch 15, wobei der computerlesbare Programmcode ferner konfiguriert ist, um geschützte Daten von dem Authentifizierungsdienst zu empfangen.