DE602005003314T2

DE602005003314T2 - Spezialisierung der Unterstützung für eine Verbandsbeziehung

Info

Publication number: DE602005003314T2
Application number: DE602005003314T
Authority: DE
Inventors: Dolapo Martin Winchester Falola; Heather Maria Winchester Hinton; Ivan Matthew Winchester Milman; Anthony Scott Winchester Moran; Patrick Ryan Winchester Wardrop
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2004-12-16
Filing date: 2005-12-15
Publication date: 2008-09-04
Anticipated expiration: 2025-12-16
Also published as: EP1672555A1; US7562382B2; US20090259753A1; EP1672555B1; US20060136990A1; TW200644539A; ATE378645T1; DE602005003314D1; US8181225B2; TWI378695B

Description

Der Erfindung zugrunde liegender allgemeiner Stand der Technik
Gebiet der Erfindung
Die vorliegende Erfindung betrifft ein verbessertes Datenverarbeitungssystem und insbesondere ein Verfahren und eine Vorrichtung zur Übertragung von Daten zwischen mehreren Rechnern. Genauer gesagt, die vorliegende Erfindung betrifft vernetzte Rechnersysteme.
Beschreibung der verwandten Technik
Im Allgemeinen möchten Unternehmen berechtigten Benutzern in vielen verschiedenen Netzwerken einschließlich des Internet durchweg auf benutzerfreundliche Weise den sicheren Zugriff auf geschützte Ressourcen ermöglichen. Obgleich die Bereitstellung von Mechanismen zur sicheren Identitätsprüfung die Risiken des unbefugten Zugriffs auf geschützte Ressourcen mindert, können sich diese Mechanismen zur Identitätsprüfung als Hindernisse für den Zugriff auf geschützte Ressourcen erweisen. Im Allgemeinen möchte ein Benutzer die Möglichkeit haben, vom Dialog mit einer Anwendung zum Dialog mit einer anderen Anwendung zu wechseln, und zwar ungeachtet der Hindernisse, die mit einer Identitätsprüfung verbunden sind, wobei diese Hindernisse aber eine Schutzfunktion für jedes einzelne System darstellen, das diese Anwendungen unterstützt.
Mit zunehmender Anspruchshaltung erwarten Benutzer, dass Rechnersysteme ihre Aktionen koordinieren, so dass sich der Aufwand für die Benutzer verringert. Diese Erwartungshaltung gilt auch für Identitätsprüfungsprozesse. Ein Benutzer nimmt möglicherweise an, dass nach einmal erfolgter Identitätsprüfung durch ein Rechnersystem dieser Identitätsnachweis für die Dauer seiner gesamten Arbeitssitzung oder zumindest über einen bestimmten Zeitraum Gültigkeit haben muss, und zwar ungeachtet der Grenzen der verschiedenen Rechnerarchitekturen, die für den Benutzer nahezu unsichtbar sind. Im Allgemeinen versuchen Unternehmen, diese Erwartungen an die Betriebseigenschaften ihrer eingesetzten Systeme zu erfüllen, nicht nur, um Benutzer nicht gegen sich aufzubringen, sondern auch, um die Leistungsfähigkeit des Benutzers zu erhöhen, und zwar ungeachtet dessen, ob es dabei um seine Produktivität als Arbeitnehmer oder um seine Zufriedenheit als Kunde geht.
Genauer gesagt, von der modernen Datenverarbeitungsumgebung, in der viele Anwendungen über eine webbasierte Benutzerschnittstelle verfügen, auf die über einen gewöhnlichen Browser zugegriffen werden kann, erwarten Benutzer eine höhere Benutzerfreundlichkeit und durch den Abbau von Hindernissen einen Zugewinn an Bewegungsfreiheit, wenn sie von einer webbasierten Anwendung zu einer anderen webbasierten Anwendung wechseln. In diesem Zusammenhang erwarten Benutzer inzwischen die Möglichkeit, vom Dialog mit einer Anwendung in einer Internet-Domäne zum Dialog mit einer anderen Anwendung in einer anderen Domäne wechseln zu können, und zwar ungeachtet der Hindernisse, die mit einer Identitätsprüfung verbunden sind, wobei diese Hindernisse aber eine Schutzfunktion für jede einzelne Domäne darstellen. Selbst wenn jedoch viele Systeme über einfach zu bedienende webbasierte Schnittstellen eine sichere Identitätsprüfung vorsehen, besteht immer noch die Möglichkeit, dass ein Benutzer gezwungenermaßen mit mehreren Identitätsprüfungsprozessen rechnen muss, die für den Benutzer beim domänenübergreifenden Zugriff ein Hindernis darstellen. Wenn man einen Benutzer innerhalb eines bestimmten Zeitrahmens mit mehreren Identitätsprüfungsprozessen konfrontiert, kann dies zu einer erheblichen Einbuße seiner Leistungsfähigkeit führen.
Es wurden beispielsweise verschiedene Verfahren eingesetzt, um den mit der Identitätsprüfung verbundenen Aufwand für Benutzer und Administratoren von Rechnersystemen zu verringern. Diese Verfahren werden allgemein als Einmalanmeldeprozesse ("single-sign-on" (SSO)) beschrieben, da sie einem gemeinsamen Zweck dienen: Nachdem ein Benutzer eine Anmeldeoperation durchgeführt hat, d. h., nachdem seine Identität bestätigt wurde, braucht der Benutzer anschließend keine weitere Identitätsprüfungsoperation durchzuführen. Folglich besteht das Ziel darin, dass der Benutzer während einer bestimmten Sitzung nur einen einzigen Identitätsprüfungsprozess durchführen muss.
Um die Kosten für die Verwaltung von Benutzern zu senken und die Möglichkeit der Zusammenarbeit zwischen Unternehmen zu verbessern, wurden Verbund-Datenverarbeitungsbereiche geschaffen. Ein Verbund ist eine lose Verbindung von Unternehmen, die sich an bestimmte, für die Zusammenarbeit untereinander gültige Standards halten; der Verbund stellt einen Mechanismus zur Schaffung einer Vertrauensstellung zwischen diesen Unternehmen in Bezug auf bestimmte Datenverarbeitungsoperationen der Benutzer in dem Verbund bereit. Ein Verbundpartner kann zum Beispiel die Funktion einer Heimdomäne oder eines Identitätsanbieters eines Benutzers übernehmen. Andere Partner innerhalb desselben Verbunds können sich auf den Identitätsanbieter des Benutzers bei der Erstverwaltung der Anmeldedaten des Benutzers verlassen, beispielsweise können sie ein Kennzeichen (Token) für die Einmalanmeldung akzeptieren, das vom Identitätsanbieter des Benutzers bereitgestellt wird.
Wenn Unternehmen Maßnahmen zur Unterstützung von Geschäftsbeziehungen im Verbund ergreifen, sollten diese Unternehmen den Benutzer eine Erfahrung machen lassen, in der sich die wachsende Zusammenarbeit zwischen zwei Unternehmen widerspiegelt. Wie zuvor erwähnt wurde, kann ein Benutzer seine Identität gegenüber einer Partei, die die Funktion eines Identitätsanbieters hat, nachweisen und sich dann einmalig bei einem Geschäftspartner im Verbund anmelden, der die Funktion eines Diensteanbieters hat. In Verbindung mit dieser Funktionalität zur Einmalanmeldung sollten auch zusätzliche Funktionen zur Lebenszyklusverwaltung des Benutzers, wie zum Beispiel eine Kontenverknüpfung/Aufhebung der Kontenverknüpfung und eine Einmalabmeldung, unterstützt werden, und zwar jeweils so, dass diese Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund (federated user lifecycle management (FULM)) weder bei der einen noch bei der anderen Partei eine Änderung der Infrastruktur erforderlich macht.
Moderne Datenverarbeitungsumgebungen haben Probleme mit der Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund dadurch gelöst, dass sie nur Funktionen zur Einmalanmeldung bereitstellen oder unternehmenseigene Protokolle verwenden. Diese Lösungen sind jedoch nicht skalierbar, um die Voraussetzungen für eine "lose verbundene" Umgebung zu schaffen, eine Umgebung, in der neue Partner problemlos in den Rechnerdialog aufgenommen oder alte Partner aus der Datenverarbeitungsumgebung entfernt werden können, ohne auf der einen oder der anderen Seite Änderungen an der Umgebung vornehmen zu müssen. Bei diesen Lösungen nach dem Stand der Technik handelt es sich um ausgesprochene Partner-zu-Partner-Lösungen, die alle einzeln verwaltet wurden; die Skalierbarkeit dieses Ansatzes stellte ein Hemmnis für eine Übernahme auf breiter Front dar.
Die veröffentlichte US-Patentanmeldung 2004/0098585 legt Verfahren, Systeme, Rechnerprogrammprodukte und Geschäftsmethoden offen, die sowohl den Zugriff auf eine ältere Anwendung auf einem Hostrechner/auf ein älteres Hostrechnersystem als auch eine Einmalanmeldung in einer modernen verteilten Datenverarbeitungsumgebung gemeinsam vorsehen. Ein für die Anmeldung in der modernen Datenverarbeitungsumgebung verwendetes Sicherheits-Token wird wirksam eingesetzt und auf die Zugangsdaten des Benutzers für die Umgebung mit dem älteren Hostrechner abgebildet. Diese Zugangsdaten des Benutzers werden programmatisch in einen Datenstrom des älteren Hostrechners eingefügt, wodurch dem Endbenutzer das Bild und das Gefühl eines nahtlosen Zugriffs auf alle Anwendungen/Systeme vermittelt wird, zu denen nicht nur moderne Datenverarbeitungsanwendungen/-systeme, sondern auch diejenigen Anwendungen und Systeme gehören, die sich auf älteren Hostrechnern befinden (oder über diese zugänglich sind).
Es wäre folglich von Vorteil, über Verfahren und Systeme zu verfügen, die eine Herstellung von Verbundbeziehungen zwischen Verbundpartnern und die gleichzeitige Verwaltung dieser Verbundbeziehungen mittels Software ermöglichen.
ZUSAMMENFASSUNG DER ERFINDUNG
Gemäß einem ersten Aspekt wird ein Verfahren bereitgestellt, mittels dem Verbundfunktionen in einem Datenverarbeitungssystem bereitgestellt werden, wobei das Verfahren Folgendes umfasst: Empfangen einer ersten Anforderung für Verbunddienste von einem Identitätsanbieter an einem ersten Datenverarbeitungssystem, wobei die erste Anforderung von einem ersten Anforderer gestellt wird; Initialisieren einer ersten individuell festgelegten Laufzeit, die angeforderte Verbunddienste für den ersten Anforderer gemäß Konfigurationsdaten einer Verbundbeziehung des ersten Anforderers mit dem Identitätsanbieter bereitstellt, wobei die Konfigurationsdaten während der Initialisierung der Laufzeit dynamisch abgerufen werden; und Bereitstellen der angeforderten Verbunddienste unter Nutzung der individuell festgelegten Laufzeit.
Gemäß einem weiteren Aspekt wird ein System bereitgestellt, das einen Speicher und einen Prozessor enthält, um in einem Datenverarbeitungssystem Verbundfunktionen bereitzustellen, wobei das System Folgendes umfasst: ein Mittel, um eine erste Anforderung für Verbunddienste von einem Identitätsanbieter an einem ersten Datenverarbeitungssystem zu empfangen, wobei die erste Anforderung von einem ersten Anforderer gestellt wird; ein Mittel, um eine erste individuell festgelegte Laufzeit zu initialisieren, die angeforderte Verbunddienste für den ersten Anforderer gemäß Konfigurationsdaten einer Verbundbeziehung des ersten Anforderers mit dem Identitätsanbieter bereitstellt, wobei die Konfigurationsdaten während der Initialisierung der Laufzeit dynamisch abgerufen werden; und ein Mittel, um die angeforderten Verbunddienste unter Nutzung der individuell festgelegten Laufzeit bereitzustellen.
Gemäß einem weiteren Aspekt wird ein Rechnerprogrammprodukt Verfahren auf einem rechnerlesbaren Datenträger bereitgestellt, um Verbundfunktionen in einem Datenverarbeitungssystem bereitzustellen, wobei das Rechnerprogrammprodukt Folgendes umfasst: ein Mittel, um eine erste Anforderung für Verbunddienste von einem Identitätsanbieter an einem ersten Datenverarbeitungssystem zu empfangen, wobei die erste Anforderung von einem ersten Anforderer gestellt wird; ein Mittel, um eine erste individuell festgelegte Laufzeit zu initialisieren, die angeforderte Verbunddienste für den ersten Anforderer gemäß Konfigurationsdaten einer Verbundbeziehung des ersten Anforderers mit dem Identitätsanbieter bereitstellt, wobei die Konfigurationsdaten während der Initialisierung der Laufzeit dynamisch abgerufen werden; und ein Mittel, um die angeforderten Verbunddienste unter Nutzung der individuell festgelegten Laufzeit bereitzustellen.
Gemäß einer Ausführungsform stellt die Erfindung mittels mehrerer individuell festgelegter Laufzeiten Verbundfunktionen in einem Datenverarbeitungssystem bereit. Jede der Vielzahl der individuell festgelegten Laufzeiten stellt vorzugsweise angeforderte Verbunddienste für einzelne ausgewählte Anforderer in Übereinstimmung mit Konfigurationsdaten der jeweiligen Verbundbeziehungen der Anforderer mit dem Identitätsanbieter bereit. Die Konfigurationsdaten werden während der Initialisierung der Laufzeiten vorzugsweise dynamisch abgerufen, wodurch die jeweilige Laufzeit für eine bestimmte Verbundbeziehung individuell festgelegt werden kann. Wenn gemäß einer Ausführungsform eine erste Anforderung von einem ersten Anforderer für Verbunddienste von einem Identitätsanbieter gestellt wird, leitet der Identitätsanbieter die Anforderung vorzugsweise an die entsprechende individuell festgelegte Laufzeit weiter, wobei er die Identität des ersten Anforderers und die gegebene Verbundbeziehung verwendet.
In einer Ausführungsform der vorliegenden Erfindung kann dieselbe individuell festgelegte Laufzeit einer Vielzahl von Anforderern Verbunddienste bereitstellen. In dem Fall, in dem eine Vielzahl von Anforderern von einer bestimmten individuell festgelegten Laufzeit bedient wird, wird die Laufzeit vorzugsweise entsprechend den Konfigurationsdaten einer Verbundbeziehung eines jeden der zugehörigen Anforderer initialisiert. Indem man eine Vielzahl von individuell festgelegten Laufzeiten verwendet, können Anforderern vorzugsweise weitgehend gleiche Verbunddienste bereitgestellt werden, wobei sich Änderungen, die an den Konfigurationsdaten eines Anforderers vorgenommen werden, nicht auf einen anderen Anforderer auswirken.
In der bevorzugten Ausführungsform der Erfindung werden die Daten, die jede Verbundbeziehung zwischen dem Identitätsanbieter und jedem Anforderer der Vielzahl der Anforderer beschreiben, vor der Initialisierung der Laufzeiten konfiguriert. Vorzugsweise können angegebene globale Daten, die allen Verbundbeziehungen mit der Ebene des Identitätsanbieters gemeinsam sind, konfiguriert werden. Überdies werden vorzugsweise Daten über eine Verbundbeziehung, die speziell für die erste individuell festgelegte Laufzeit gelten, konfiguriert, die die globalen Daten möglicherweise überschreiben können. Darüber hinaus können vorzugsweise Daten, die speziell für einen Anforderer gelten, konfiguriert werden, die die globalen Daten oder die Daten über eine Verbundbeziehung gegebenenfalls überschreiben können. Indem die Konfigurationsdaten auf diese Weise aufgeteilt werden, ist der Umfang der Änderungen, die an den Daten vorgenommen werden müssen, gering, wodurch das Hinzufügen oder das Entfernen von Anforderern vom Standpunkt der Verwaltung aus betrachtet äußerst skalierbar wird.
Vorzugsweise werden Verfahren und Systeme bereitgestellt, die die Herstellung von Verbundbeziehungen zwischen Verbundpartnern und die gleichzeitige Verwaltung dieser Verbundbeziehungen mittels Software ermöglichen.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Ausführungsformen der vorliegenden Erfindung werden nun lediglich anhand eines Beispiels und mit Bezug auf die folgenden Zeichnungen beschrieben:
1A zeigt ein typisches Netzwerk aus Datenverarbeitungssystemen, wobei jedes Datenverarbeitungssystem die vorliegende Erfindung gemäß einer Ausführungsform realisieren kann;
1B zeigt eine typische Rechnerarchitektur, die in einem Datenverarbeitungssystem verwendet werden kann, in dem eine Ausführungsform der vorliegenden Erfindung realisiert werden kann;
1C ist ein Datenflussdiagramm, das einen typischen Prozess der Identitätsprüfung gemäß einer Ausführungsform veranschaulicht, der eingesetzt werden kann, wenn ein Client versucht, auf eine geschützte Ressource auf einem Server zuzugreifen;
1D ist eine Darstellung von Netzwerken, die eine typische webbasierte Umgebung zeigt, in der die vorliegende Erfindung gemäß einer Ausführungsform realisiert werden kann;
1E ist ein Blockschaubild, das ein Beispiel für eine typische Online-Transaktion zeigt, die gegebenenfalls mehrere Identitätsprüfungsoperationen eines Benutzers erforderlich macht;
2A ist ein Blockschaubild, das gemäß einer Ausführungsform die Terminologie der Verbundumgebung in Bezug auf eine Transaktion veranschaulicht, die von einem Benutzer eingeleitet wird und an ein erstes Verbundunternehmen gerichtet ist, das als Reaktion darauf Aktionen an nachgelagerten (downstream) Einheiten in der Verbundumgebung aufruft;
2B ist ein Blockschaubild, das die Einbindung von Systemen, die in einer bestimmten Domäne bereits vorhanden sind, in einige der Komponenten der Verbundarchitektur der vorliegenden Erfindung gemäß einer Ausführungsform der vorliegenden Erfindung veranschaulicht;
2C ist ein Blockschaubild, das eine Verbundarchitektur gemäß einer realisierten Ausführungsform der vorliegenden Erfindung veranschaulicht;
2D ist ein Blockschaubild, das mehrere beispielhafte Vertrauensbeziehungen zwischen Verbunddomänen unter Verwendung von vertrauenswürdigen Proxys und einem vertrauenswürdigen Vermittler (trust broker) gemäß einer Ausführungsform der vorliegenden Erfindung veranschaulicht;
3A ist ein Flussdiagramm, das gemäß einer Ausführungsform der vorliegenden Erfindung einen verallgemeinerten Prozess in einer ausgebenden Domäne zur Erzeugung einer Bestätigung (assertion) in einer Verbundumgebung veranschaulicht;
3B ist ein Flussdiagramm, das gemäß einer Ausführungsform der vorliegenden Erfindung einen verallgemeinerten Prozess in einer sich auf die Vertrauenswürdigkeit verlassenden Domäne (relying domain) zur Aufhebung einer Bestätigung veranschaulicht;
3C ist ein Flussdiagramm, das gemäß einer Ausführungsform der vorliegenden Erfindung einen bestimmten Prozess veranschaulicht, der dazu dient, eine Bestätigung von einer ausgebenden Domäne als Reaktion auf eine in der ausgebenden Domäne stattfindende Benutzeraktion an eine sich auf die Vertrauenswürdigkeit verlassende Domäne zu senden;
3D ist ein Flussdiagramm, das gemäß einer Ausführungsform der vorliegenden Erfindung einen bestimmten Prozess veranschaulicht, der dazu dient, eine Bestätigung von einer ausgebenden Domäne an eine sich auf die Vertrauenswürdigkeit verlassende Domäne zu senden, und zwar als Reaktion darauf, dass die ausgebende Domäne aktiv eine abgehende Anforderung an die sich auf die Vertrauenswürdigkeit verlassende Domäne abfängt;
3E ist ein Flussdiagramm, das gemäß einer Ausführungsform der vorliegenden Erfindung ein Empfangsmodell veranschaulicht, bei dem eine sich auf die Vertrauenswürdigkeit verlassende Domäne erforderliche Bestätigungen für einen Benutzer von einer ausgebenden Domäne anfordert, während sie versucht, eine Anforderung für eine Ressource zu erfüllen, welche die sich auf die Vertrauenswürdigkeit verlassende Domäne von dem anfordernden Benutzer empfangen hat;
4 ist ein Blockschaubild, das gemäß einer Ausführungsform der vorliegenden Erfindung eine Verbundumgebung zeigt, die Einmalanmeldeoperationen im Verbund unterstützt;
5 ist ein Blockschaubild, das einige der Komponenten in einer Verbunddomäne zur Umsetzung der Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund gemäß einer Ausführungsform der vorliegenden Erfindung zeigt;
6 ist ein Datenflussdiagramm, das einen Prozess zur Durchführung einer Einmalanmeldeoperation unter Nutzung der Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund gemäß einer Ausführungsform der vorliegenden Erfindung zeigt;
7 ist ein Blockschaubild, das gemäß einer Ausführungsform der vorliegenden Erfindung einen Aufbau logischer Komponenten zeigt, der die Verwaltung von Vertrauensbeziehungen von der Verwaltung des Lebenszyklus des Benutzers im Verbund trennt;
8A ist ein Blockschaubild, das gemäß einer Ausführungsform der vorliegenden Erfindung eine hohe Abstraktionsebene der logischen Funktionalität einer Datenverarbeitungs-Verbundumgebung zeigt;
8B ist ein Blockschaubild, das eine hohe Abstraktionsebene der logischen Funktionalität einer Datenverarbeitungs-Verbundumgebung zeigt, die die Art und Weise veranschaulicht, in der eine Ausführungsform der vorliegenden Erfindung die Trennung der Verbundfunktionalität und der Funktionalität der Kontaktstelle von der Funktionalität zur Verwaltung von Vertrauensbeziehungen vorsieht;
8C ist ein Blockschaubild, das eine hohe Abstraktionsebene der logischen Funktionalität einer Datenverarbeitungs-Verbundumgebung zeigt, die die Art und Weise veranschaulicht, in der eine Ausführungsform der vorliegenden Erfindung die weitere Trennung der Verbund-Betriebsfunktionalität von der Funktionalität der Kontaktstelle vorsieht;
8D ist ein Blockschaubild, das eine hohe Abstraktionsebene der logischen Funktionalität einer Datenverarbeitungs-Verbundumgebung zeigt, die die Art und Weise veranschaulicht, in der eine Ausführungsform der vorliegenden Erfindung die weitere Trennung der Verbund-Betriebsfunktionalität in die Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund und in die Funktionalität zur Verwaltung von Beziehungen im Verbund vorsieht;
Die 9A bis 9B zeigen Venn-Diagramme, die gemäß einer Ausführungsform der vorliegenden Erfindung eine jeweils unterschiedliche Art und Weise zeigen, in der eine Verbundbeziehung eine Vertrauensbeziehung in Verbindung mit einer Auswahl an Verbundfunktionen beinhaltet;
10 ist ein Datenflussdiagramm, das gemäß einer Ausführungsform der vorliegenden Erfindung mehrere Operationen zeigt, die von zwei als Paar zugeordneten Geschäftspartnern durchgeführt werden, um in einer Datenverarbeitungs-Verbundumgebung interaktiv miteinander zu kommunizieren;
11 ist ein Blockschaubild, das gemäß einer Ausführungsform der vorliegenden Erfindung einen Dialogverkehr zwischen Geschäftspartnern zeigt, um in Vorbereitung der Herstellung einer Verbundbeziehung zunächst eine Vertrauensbeziehung aufzubauen.
12 ist ein Blockschaubild, das gemäß einer Ausführungsform der vorliegenden Erfindung eine Konfiguration einer Datenverarbeitungsumgebung zur Einbindung einer Verbundfunktionalität zeigt;
13A ist ein Blockschaubild, das gemäß einer Ausführungsform der vorliegenden Erfindung eine Konsolenanwendung zur Verwaltung von Verbundbeziehungen zeigt, die von einem Benutzer, der als Systemadministrator tätig ist, verwendet werden kann, um Verbundbeziehungen in der Datenverarbeitungsumgebung eines Unternehmens herzustellen;
13B ist eine schematische Darstellung, die gemäß einer Ausführungsform der vorliegenden Erfindung ein Fenster einer grafischen Benutzeroberfläche in einer Anwendung zur Verwaltung von Verbundbeziehungen zeigt, das von einem als Administrator tätigen Benutzer verwendet werden kann, um Verbundbeziehungen zwischen Verbundpartnern herzustellen;
Die 13C bis 13D sind Blockschaubilder, die gemäß einer Ausführungsform der vorliegenden Erfindung Datenflüsse zeigen, die von einer Konsolenanwendung zur Verwaltung von Verbundbeziehungen gestartet werden, um zur Herstellung von Verbundbeziehungen in der Datenverarbeitungsumgebung eines Unternehmens partnerspezifische Daten zu erhalten;
14 ist ein Flussdiagramm, das gemäß einer Ausführungsform der vorliegenden Erfindung einen Prozess zeigt, durch den automatisch eine Verbundbeziehung hergestellt wird, indem eine exportierte/importierte Datei verwendet wird, die zwischen Verbundpartnern ausgetauscht wird, die über die Verbundbeziehung interaktiv miteinander kommunizieren;
15 stellt ein Verbund-Blockschaubild dar, das gemäß einer Ausführungsform der vorliegenden Erfindung eine Konfiguration einer Datenverarbeitungsumgebung zur Einbindung einer Verbundfunktionalität zeigt; und
die 16A bis 16D sind Blockschaubilder, die gemäß einer Ausführungsform der vorliegenden Erfindung Datenflüsse zeigen, um zur Herstellung von Verbundbeziehungen in einer Datenverarbeitungsumgebung eines Unternehmens Daten zu konfigurieren.
AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG
Im Allgemeinen beinhalten die Einheiten, die die vorliegende Erfindung bilden oder zu ihr gehören können, viele verschiedene Datenverarbeitungstechnologien. Bevor die vorliegende Erfindung gemäß einer Ausführungsform ausführlicher dargelegt wird, wird folglich als Hintergrundinformation ein typischer Aufbau von Hardware- und Softwarekomponenten in einem verteilten Datenverarbeitungssystem beschrieben.
Nun Bezug nehmend auf die Figuren zeigt 1A ein typisches Netzwerk aus Datenverarbeitungssystemen, wobei jedes Datenverarbeitungssystem eine Ausführungsform der vorliegenden Erfindung realisieren kann. Das verteilte Datenverarbeitungssystem 100 enthält das Netzwerk 101, das ein Medium ist, welches zur Bereitstellung von Datenübertragungsverbindungen zwischen verschiedenen Einheiten und Rechnern verwendet werden kann, die in dem verteilten Datenverarbeitungssystem 100 miteinander verbunden sind. Das Netzwerk 101 kann feste Verbindungen wie zum Beispiel Draht- oder Lichtwellenleiterkabel oder zeitweilige Verbindungen beinhalten, die über Telefon- oder drahtlose Übertragungen erfolgen. In dem gezeigten Beispiel sind der Server 102 und der Server 103 zusammen mit der Speichereinheit 104 an das Netzwerk 101 angeschlossen. Überdies sind auch die Clients 105 bis 107 an das Netzwerk 101 angeschlossen. Die Clients 105 bis 107 und die Server 102 bis 103 können von einer Vielzahl von Rechnereinheiten wie zum Beispiel Großrechner, Personal Computer, persönliche digitale Assistenten (PDAs) usw. dargestellt werden. Das verteilte Datenverarbeitungssystem 100 kann zusätzliche Server, Clients, Router und andere Einheiten sowie Architekturen zwischen Gleichgestellten (Peer-zu-Peer-Architekturen) enthalten, die nicht gezeigt sind.
In dem gezeigten Beispiel kann das verteilte Datenverarbeitungssystem 100 das Internet mit dem Netzwerk 101 enthalten, das einen weltweiten Verbund von Netzwerken und Verbindungsrechnern (Gateways) darstellt, die verschiedene Protokolle verwenden, um Daten miteinander auszutauschen, wie zum Beispiel LDAP (Lightweight Directory Access Protocol), TCP/IP (Transport Control Protocol/Internet Protocol), HTTP (HyperText Transport Protocol) usw. Natürlich kann das verteilte Datenverarbeitungssystem 100 auch mehrere unterschiedliche Arten von Netzwerken wie zum Beispiel ein Intranet, ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetz (WAN) enthalten. Der Server 102 unterstützt beispielsweise direkt den Client 109 und das Netzwerk 110, das drahtlose Datenübertragungsverbindungen enthält. Das netzwerkfähige Telefon 111 ist über die drahtlose Verbindung 112 an das Netzwerk 110 angeschlossen, und der PDA 113 ist über die drahtlose Verbindung 114 an das Netzwerk 110 angeschlossen. Das Telefon 111 und der PDA 113 können mittels einer geeigneten Technologie wie zum Beispiel der drahtlosen Technologie Bluetooth^TM über die drahtlose Verbindung 115 auch direkt Daten miteinander austauschen, um so genannte Personal Area Networks oder persönliche Ad-hoc-Netzwerke aufzubauen. Auf ähnliche Weise kann der PDA 113 Daten über die drahtlose Datenübertragungsverbindung 116 an den PDA 107 übertragen.
Die vorliegende Erfindung könnte auf vielen verschiedenen Hardware-Plattformen und in vielen verschiedenen Software-Umgebungen realisiert werden. 1A ist als Beispiel einer heterogenen Datenverarbeitungsumgebung und nicht als architektonische Beschränkung der vorliegenden Erfindung zu verstehen.
Nun Bezug nehmend auf 1B zeigt eine Übersichtsdarstellung eine typische Rechnerarchitektur eines Datenverarbeitungssystems, wie zum Beispiel eines der in 1A gezeigten Datenverarbeitungssysteme, in dem eine Ausführungsform der vorliegenden Erfindung realisiert werden kann. Das Datenverarbeitungssystem 120 enthält eine oder mehrere Zentraleinheiten (CPUs) 122, die mit dem internen Systembus 123 verbunden sind, der den Speicher mit wahlfreiem Zugriff (RAM) 124, den Nur-Lese-Speicher 126 und den Eingabe-/Ausgabeadapter 128 miteinander verbindet, welcher wiederum verschiedene E/A-Einheiten wie zum Beispiel den Drucker 130, die Platteneinheiten 132 oder andere Einheiten, die nicht gezeigt sind, wie zum Beispiel ein Audioausgabesystem usw. unterstützt. Über den Systembus 123 ist auch der Datenübertragungsadapter 134 angeschlossen, der den Zugriff auf die Datenübertragungsverbindung 136 ermöglicht. Der Benutzerschnittstellenadapter 148 verbindet verschiedene Benutzereinheiten wie zum Beispiel die Tastatur 140 und die Maus 142 oder andere Einheiten, die nicht gezeigt sind, wie zum Beispiel einen berührungsempfindlichen Bildschirm, einen Stift, ein Mikrofon usw. Der Bildschirmadapter 144 verbindet den Systembus 123 mit dem Bildschirm 146.
Der Fachmann versteht, dass die in 1B gezeigte Hardware in Abhängigkeit von der Ausführung des Systems unterschiedlich sein kann. Beispielsweise kann das System über einen oder mehrere Prozessoren, zum Beispiel einen auf dem Pentium^® von Intel^® beruhenden Prozessor, und einen digitalen Signalprozessor (DSP) sowie eine oder mehrere Arten eines flüchtigen und eines nichtflüchtigen Speichers verfügen. (Intel und Pentium sind Warenzeichen beziehungsweise eingetragene Warenzeichen der Intel Corporation oder ihrer Tochtergesellschaften in den Vereinigten Staaten von Amerika und anderen Ländern.) Zusätzlich zu oder anstelle der in 1B gezeigten Hardware können andere Peripheriegeräte verwendet werden. Die gezeigten Beispiele sind nicht als architektonische Beschränkungen der vorliegenden Erfindung zu verstehen.
Die vorliegende Erfindung kann nicht nur auf vielen verschiedenen Hardware-Plattformen, sondern auch in einer Vielzahl von Software-Umgebungen realisiert werden. Ein gewöhnliches Betriebssystem kann zur Steuerung der Programmausführung in jedem Datenverarbeitungssystem eingesetzt werden. So kann eine Einheit beispielsweise das Betriebssystem Unix^® ausführen, während eine andere Einheit eine einfache Java^®-Laufzeitumgebung enthält. (Java und alle auf Java beruhenden Warenzeichen und Logos sind Warenzeichen der Sun Microsystems, Inc. in den Vereinigten Staaten von Amerika, in anderen Ländern oder sowohl in den Vereinigten Staaten von Amerika als auch in anderen Ländern; UNIX ist ein eingetragenes Warenzeichen von The Open Group in den Vereinigten Staaten von Amerika und in anderen Ländern.) Eine repräsentative Rechnerplattform kann einen Browser enthalten, bei dem es sich um eine bekannte Software-Anwendung zum Zugriff auf Hypertext-Dokumente in vielen verschiedenen Formaten wie zum Beispiel Grafikdateien, Textverarbeitungsdateien, Extensible-Markup-Language-(XML-), Hypertext-Markup-Language-(HTML-), Handheld-Device-Markup-Language-(HDML-), Wireless-Markup-Language-(WML-)Dateien und verschiedene andere Formate und Dateitypen handelt. Es sei auch erwähnt, dass das in 1A gezeigte verteilte Datenverarbeitungssystem als ein Datenverarbeitungssystem zu verstehen ist, das uneingeschränkt in der Lage ist, viele verschiedene Teilnetze und Dienste unter Gleichengestellten (Peer-zu-Peer-Teilnetze und Peer-zu-Peer-Dienste) zu unterstützen.
Nun Bezug nehmend auf 1C zeigt ein Datenflussdiagramm einen typischen Prozess der Identitätsprüfung, der eingesetzt werden kann, wenn ein Client versucht, auf eine geschützte Ressource auf einem Server zuzugreifen. Wie gezeigt ist, versucht der Benutzer an einem Client-Arbeitsplatzrechner 150 mittels seines Webbrowsers, der auf dem Client-Arbeitsplatzrechner läuft, über ein Rechnernetzwerk auf eine geschützte Ressource auf einem Server 151 zuzugreifen. Eine geschützte oder kontrollierte Ressource ist eine Ressource (eine Anwendung, ein Objekt, ein Dokument, eine Seite, eine Datei, ein ausführbarer Code oder eine andere Datenverarbeitungs- oder Datenübertragungsressource usw.), auf die der Zugriff eingeschränkt ist oder kontrolliert wird. Eine geschützte Ressource ist durch eine Verweisadresse mit der Bezeichnung Uniform Resource Locator (URL) oder allgemeiner Uniform Resource Identifier (URI) gekennzeichnet, auf die nur ein Benutzer zugreifen kann, dessen Identität bestätigt wurde und/oder der über eine entsprechende Berechtigung verfügt. Das Rechnernetzwerk kann das Internet, ein Intranet oder ein anderes Netzwerk sein, wie in 1A oder 1B gezeigt ist, und der Server kann ein Server für Webanwendungen (web application server (WAS)), eine Server-Anwendung, ein Servlet-Prozess oder dergleichen sein.
Der Prozess wird eingeleitet, wenn der Benutzer eine serverseitige geschützte Ressource wie zum Beispiel eine Webseite in der Domäne "ibm.com" anfordert (Schritt 152). Die Begriffe "serverseitig" und "clientseitig" beziehen sich auf Aktionen oder Einheiten auf einem Server beziehungsweise auf einem Client in einer vernetzten Umgebung. Der Webbrowser (oder eine zugehörige Anwendung oder ein zugehörigs Applet) erzeugt eine HTTP-Anforderung (Schritt 153), die an denjenigen Webserver gesendet wird, auf dem sich die Domäne "ibm.com" befindet. Die Begriffe "Anforderung" ("request") und "Antwort" ("response") sind so zu verstehen, dass sie die Formatierung von Daten in einer Weise beinhalten, welche für die Übertragung von Daten, die zu einer bestimmten Operation gehören, wie zum Beispiel Nachrichten, Übertragungsprotokoll-Daten oder andere zugehörige Daten, geeignet ist.
Der Server stellt fest, dass er keine aktive Sitzung für den Client hat (Schritt 154), so dass der Server den Aufbau einer Secure-Sockets-Lager-(SSL-)Sitzung zwischen ihm und dem Client einleitet und fertig stellt (Schritt 155), was mehrere Übertragungen von Daten zwischen dem Client und dem Server mit sich bringt. Nachdem eine SSL-Sitzung aufgebaut wurde, werden nachfolgende Übertragungsnachrichten im Rahmen der SSL-Sitzung übertragen; geheime Daten bleiben sicher, da die Übertragungsnachrichten bei der SSL-Sitzung verschlüsselt sind.
Der Server muss jedoch die Identität des Benutzers feststellen, bevor er ihm den Zugriff auf geschützte Ressourcen gestattet, so dass er den Benutzer auffordert, einen Identitätsprüfungsprozess durchzuführen, indem er dem Client irgendeine Zufallszahl (Challenge) zum Zweck der Identitätsprüfung sendet (Schritt 156). Die Zufallszahl zum Zweck der Identitätsprüfung kann unterschiedliche Formate, zum Beispiel HTML, haben. Anschließend stellt der Benutzer die angeforderten oder benötigten Daten wie zum Beispiel einen Benutzernamen oder eine andere Art einer Benutzerkennung zusammen mit einem zugehörigen Passwort oder einer anderen Form einer geheimem Information bereit (Schritt 157).
Die Antwortdaten der Identitätsprüfung werden an den Server gesendet (Schritt 158), wobei der Server an diesem Punkt die Identität des Benutzers oder des Client prüft (Schritt 159), zum Beispiel, indem er zuvor übergebene Registrierungsdaten abruft und die zum Zweck der Identitätsprüfung übergebenen Daten mit den gespeicherten Daten des Benutzers vergleicht. Unter der Annahme, dass die Identitätsprüfung erfolgreich verläuft, wird für den Benutzer oder Client, dessen Identität bestätigt wurde, eine aktive Sitzung aufgebaut. Der Server erzeugt eine Sitzungskennung für den Client, und allen nachfolgenden Anforderungsnachrichten, die der Client während der Sitzung schickt, würde die Sitzungskennung angefügt werden.
Der Server ruft dann die ursprünglich angeforderte Webseite ab und sendet eine HTTP-Antwortnachricht an den Client (Schritt 160), wodurch er die ursprüngliche Anforderung des Benutzers für die geschützte Ressource erfüllt. An diesem Punkt kann der Benutzer eine weitere Seite der Domäne "ibm.com" anfordern (Schritt 161), indem er eine Hypertext-Verknüpfung in einem Browser-Fenster anklickt, und der Browser sendet eine weitere HTTP-Anforderungsnachricht an den Server (Schritt 162). Nun erkennt der Server, dass die Sitzung des Benutzers aktiv ist (Schritt 163), da die Sitzungskennung des Benutzers in der HTTP-Anforderungsnachricht an den Server zurückgeschickt wird, und der Server sendet die angeforderte Webseite in einer anderen HTTP-Antwortnachricht zurück an den Client (Schritt 164). Zwar zeigt 1C einen typischen Prozess nach dem Stand der Technik, doch sei angemerkt, dass auch andere alternative Verfahren zur Verwaltung des Sitzungsstatus dargestellt werden könnten, zum Beispiel Verfahren, bei denen die URL zurückgeschrieben wird oder Cookies verwendet werden, um Benutzer mit aktiven Sitzungen festzustellen, wobei bei letzterem Verfahren dasselbe Cookie verwendet werden könnte, das auch zur Erbringung des Nachweises der Identität verwendet wird.
Nun Bezug nehmend auf 1D zeigt eine Darstellung von Netzwerken eine typische webbasierte Umgebung, in der eine Ausführungsform der vorliegenden Erfindung realisiert werden kann. In dieser Umgebung möchte ein Benutzer eines Browser 170 am Client 171 auf eine geschützte Ressource auf dem Web-Anwendungsserver 172 in der DNS-Domäne 173 oder auf dem Web-Anwendungsserver 174 in der DNS-Domäne 175 zugreifen.
In einer Weise, die der in 1C gezeigten Weise ähnlich ist, kann ein Benutzer eine geschützte Ressource in einer von vielen Domänen anfordern. Im Gegensatz zu 1C, die nur einen einzigen Server in einer bestimmten Domäne zeigt, hat jede Domäne in 1D mehrere Server. Insbesondere kann jede Domäne über einen zugehörigen Identitätsprüfungsserver 176 und 177 verfügen.
Nachdem der Client 171 eine Anforderung für eine geschützte Ressource in der Domäne 173 ausgegeben hat, stellt der Web-Anwendungsserver 172 in diesem Beispiel fest, dass er keine aktive Sitzung für den Client 171 hat, und er stellt die Anforderung, dass der Identitätsprüfungsserver 176 mit dem Client 171 eine entsprechende Operation zur Identitätsprüfung durchführt. Der Identitätsprüfungsserver 176 übermittelt dem Web-Anwendungsserver 172 das Ergebnis der Identitätsprüfungsoperation. Wenn die Identität des Benutzers (oder des Browser 170 oder des Client 171 im Namen des Benutzers) erfolgreich geprüft wurde, baut der Web-Anwendungsserver 172 eine Sitzung für den Client 171 auf und sendet die angeforderte geschützte Ressource zurück. Sobald die Identität des Benutzers vom Identitätsprüfungsserver bestätigt wurde, wird in einem Cookie-Cachespeicher im Browser üblicherweise ein Cookie gesetzt und gespeichert. 1D stellt lediglich ein Beispiel für eine Art und Weise dar, in der die Verarbeitungsressourcen einer Domäne unter mehreren Servern freigegeben werden können, insbesondere, um Operationen zur Identitätsprüfung durchzuführen.
Nachdem der Client 171 eine Anforderung für eine geschützte Ressource in der Domäne 175 ausgegeben hat, führt der Identitätsprüfungsserver 177 in ähnlicher Weise eine entsprechende Operation zur Identitätsprüfung mit dem Client 171 durch, woraufhin der Web-Anwendungsserver 174 eine Sitzung für den Client 171 aufbaut und die angeforderte geschützte Ressource zurückschickt. Folglich zeigt 1D, dass der Client 171 mehrere parallele Sitzungen in verschiedenen Domänen haben kann, dennoch aber mehrere Identitätsprüfungsoperationen durchführen muss, um diese parallelen Sitzungen aufbauen zu können.
Nun Bezug nehmend auf 1E zeigt ein Blockschaltbild ein Beispiel einer typischen Online-Transaktion, die gegebenenfalls mehrere Identitätsprüfungsoperationen eines Benutzers erforderlich macht. Nochmals Bezug nehmend auf 1C und 1D muss sich ein Benutzer gegebenenfalls einer Identitätsprüfungsoperation unterziehen, bevor er den Zugriff auf eine kontrollierte Ressource erlangt, wie in 1C gezeigt ist. Obgleich dies in 1C nicht gezeigt ist, kann auf dem Server 151 ein Identitätsprüfungs-Verwaltungsprogramm installiert werden, um Benutzerdaten, die zur Prüfung der Identität eines Benutzers erforderlich sind, abzurufen und zu verwenden. Wie in 1D gezeigt ist, kann ein Benutzer mehrere parallele Sitzungen in verschiedenen Domänen 173 und 175 haben, und obwohl sie in 1D nicht gezeigt sind, kann jede Domäne anstelle der Identitätsprüfungsserver oder zusätzlich zu diesen ein Identitätsprüfungs-Verwaltungsprogramm einsetzen. In ähnlicher Weise zeigt auch 1E eine Gruppe von Domänen, von denen jede eine bestimmte Art eines Verwaltungsprogramms zur Identitätsprüfung unterstützt. 1E zeigt einige der Schwierigkeiten, auf die ein Benutzer beim Zugriff auf mehrere Domänen stoßen kann, da es erforderlich ist, dass der Benutzer für jede Domäne eine Identitätsprüfungsoperation durchführt.
Der Benutzer 190 kann in der ISP-Domäne 191 angemeldet sein, die gegebenenfalls das Identitätsprüfungs-Verwaltungsprogramm 192 unterstützt, das die Identität des Benutzers 190 prüft, damit er Transaktionen in Bezug auf die Domäne 191 durchführen kann. Die ISP-Domäne 191 kann ein Internetdiensteanbieter (Internet Service Provider (ISP)) sein, der Internet-Verbindungsdienste, eMail-Dienste und möglicherweise andere Dienste für den elektronischen Handel im Internet (eCommerce-Dienste) bereitstellt. Alternativ dazu kann die ISP-Domäne 191 ein Internet-Portal sein, auf das der Benutzer 190 häufig zugreift.
Ebenso stellen die Domänen 193, 195 und 197 typische Anbieter von Webdiensten dar. Die Regierungsdomäne 193 unterstützt das Identitätsprüfungs-Verwaltungsprogramm 194, das die Identität von Benutzern zur Durchführung von verschiedenen regierungsbezogenen Transaktionen prüft. Die Domäne 195 für Bankgeschäfte unterstützt das Identitätsprüfungs-Verwaltungsprogramm (authentication manager (AM)) 196, das die Identität von Benutzern zur Durchführung von Transaktionen mit einer Online-Bank prüft. Die Domäne 197 für den elektronischen Handel im Internet (eCommerce-Domäne) unterstützt das Identitätsprüfungs-Verwaltungsprogramm 198, das die Identität von Benutzern zur Durchführung von Online-Käufen prüft.
Wie zuvor erwähnt wurde, kann ein Benutzer, wenn er versucht, im Internet oder im weltweiten Netz (World Wide Web) von einer Domäne zu einer anderen Domäne zu gelangen, indem er in den verschiedenen Domänen auf Ressourcen zugreift, mehreren Ersuchen oder Aufforderungen zum Nachweis seiner Identität unterworfen werden, wodurch er innerhalb einer Gruppe von Domänen deutlich langsamer vorankommt. Unter Verwendung von 1E als beispielhafter Umgebung ist der Benutzer 190 gegebenenfalls an einer komplizierten Online-Transaktion mit der eCommerce-Domäne 197 beteiligt, in der er versucht, einen Online-Dienst in Anspruch zu nehmen, der auf Benutzer beschränkt ist, die mindestens 18 Jahre alt sind und einen gültigen Führerschein, eine gültige Kreditkarte und ein Konto bei einer amerikanischen Bank besitzen. An dieser Online-Transaktion können die Domänen 191, 193, 195, und 197 beteiligt sein.
Üblicherweise würde ein Benutzer seine Identität und/oder Attribute nicht in jeder Domäne, die an einer gewöhnlichen Online-Transaktion beteiligt ist, verwalten. In diesem Beispiel hat sich der Benutzer 190 möglicherweise bei seinem ISP mit seinen Identifikationsdaten angemeldet, um die Online-Transaktion jedoch durchzuführen, muss er seine Identität gegebenenfalls auch gegenüber den Domänen 193, 195 und 197 nachweisen. Wenn die Identität des Benutzers in keiner der Domänen hinterlegt ist, schlägt die Online-Transaktion des Benutzers möglicherweise fehl. Selbst wenn die Identität des Benutzers von jeder Domäne nachgewiesen werden könnte, ist nicht gewährleistet, dass die verschiedenen Domänen untereinander Daten übertragen können, um die Transaktion des Benutzers durchzuführen. Für den in 1E gezeigten Benutzer 190 gibt es nach dem Stand der Technik keine Umgebung, die es ihm ermöglicht, seine Identität gegenüber einer ersten Website, zum Beispiel dem ISP 191, nachzuweisen und anschließend ein Authentifizierungstoken an andere Anbieter von Webdiensten wie zum Beispiel an die Domänen 193, 195 und 197 zum Zweck der Einmalanmeldung zu übertragen.
Angesichts der vorhergehenden kurzen Beschreibung einer modernen Technologie bezieht sich die Beschreibung der restlichen Figuren auf Verbund-Rechnerumgebungen, in denen eine Ausführungsform der vorliegenden Erfindung betrieben werden kann. Bevor jedoch eine Ausführungsform der vorliegenden Erfindung ausführlicher erörtert wird, werden einige Fachbegriffe eingeführt.
Terminologie
Die Begriffe "Einheit" ("entity") oder "Partei" ("party") beziehen sich allgemein auf ein Unternehmen, einen Einzelnen oder ein System, das beziehungsweise der im Namen eines Unternehmens, eines Einzelnen oder eines anderen Systems tätig ist. Der Begriff "Domäne" bezeichnet zusätzliche Merkmale oder Eigenschaften in einer Netzwerkumgebung, aber die Begriffe "Einheit", "Partei" und "Domäne" können austauschbar verwendet werden. Der Begriff "Domäne" kann sich beispielsweise auch auf eine Domain-Name-System-(DNS-)Domäne oder allgemeiner auf ein Datenverarbeitungssystem beziehen, das verschiedene Einheiten und Anwendungen beinhaltet, die externen Einheiten als eine logische Einheit erscheinen.
Die Begriffe "Anforderung" ("request") und "Antwort" ("response") sind so zu verstehen, dass sie die Formatierung von Daten in einer Weise umfassen, welche für die Übertragung von Daten, die zu einer bestimmten Operation gehören, wie zum Beispiel Nachrichten, Übertragungsprotokoll-Daten oder andere zugehörige Daten, geeignet ist. Eine geschützte Ressource ist eine Ressource (eine Anwendung, ein Objekt, ein Dokument, eine Seite, eine Datei, ein ausführbarer Code oder eine andere Datenverarbeitungs- oder Datenübertragungsressource usw.), auf die der Zugriff eingeschränkt ist oder kontrolliert wird.
Ein Token ((bitte stehen lassen)) erbringt den direkten Nachweis für eine erfolgreiche Operation und wird von der Einheit erzeugt, die die Operation durchführt; als Beispiel sei ein Authentifizierungstoken genannt, das nach einer erfolgreichen Operation zum Nachweis der Identität erzeugt wird. Ein Kerberos-Token ist ein Beispiel für ein Authentifizierungstoken, das in einer Ausführungsform der vorliegenden Erfindung verwendet werden kann. Bezüglich weiterer Informationen über Kerberos sei auf "The Kerberos Network Authentication Service (V5)", Internet Engineering Task Force (IETF) Request for Comments (RFC) 1510, 09/1993, von Kohl u. a. verwiesen.
Eine Bestätigung erbringt den indirekten Nachweis für eine Aktion. Bestätigungen können den indirekten Nachweis der Identität, eine Identitätsprüfung, Attribute, Entscheidungen über Berechtigungszuweisungen oder andere Daten und/oder Operationen vorsehen. Eine Identitätsbestätigung (authentication assertion) erbringt den indirekten Nachweis für eine Identitätsprüfung durch eine Einheit, bei der es sich nicht um den Identitätsprüfungsdienst handelt, die aber auf den Identitätsprüfungsdienst gehört hat.
Eine Security-Assertion-Markup-Language-(SAML-)Bestätigung ist ein Beispiel für ein mögliches Bestätigungsformat, das in einer Ausführungsform der vorliegenden Erfindung verwendet werden kann. SAML wurde von der Organization for the Advancement of Structured Information Standards (OASIS), einem gemeinnützigen globalen Konsortium, veröffentlicht. SAML wird in "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML)", Committee Specification 01, 31.05.2002, wie folgt beschrieben:
Die Security Assertion Markup Language (SAML) ist ein auf XML beruhendes Rahmenwerk zum Austausch von Sicherheitsdaten. Diese Sicherheitsdaten werden in Form von Bestätigungen über Subjekte ausgedrückt, wobei ein Subjekt eine Einheit (entweder eine Person oder ein Rechner) ist, die in einer bestimmten Sicherheitsdomäne eine Identität hat. Ein typisches Beispiel für ein Subjekt ist eine Person, die in einer bestimmten DNS-Domäne im Internet durch ihre eMail-Adresse ausgewiesen ist. Bestätigungen können Informationen über Identitätsprüfungsvorgänge, die von Subjekten oder Attributen von Subjekten durchgeführt werden, und Entscheidungen über Berechtigungszuweisungen, d. h., ob Subjekte auf bestimmte Ressourcen zugreifen dürfen, übermitteln. Bestätigungen werden als XML-Konstrukte dargestellt und haben eine verschachtelte Struktur, wobei eine einzelne Bestätigung mehrere unterschiedliche interne Aussagen über die Identitätsprüfung, Berechtigungszuweisung und Attribute enthalten könnte. Es sei angemerkt, dass Bestätigungen, die Aussagen über eine Identitätsprüfung enthalten, lediglich Vorgänge der Identitätsprüfung beschreiben, die zuvor stattgefunden haben. Bestätigungen werden von SAML-Instanzen, nämlich von Identitätsprüfungsstellen, Attribut-Ausgabestellen und Richtlinien-Entscheidungsstellen (policy decision points) ausgegeben. SAML legt ein Protokoll fest, mittels dessen Clients Bestätigungen von SAML-Instanzen anfordern können und eine Antwort von ihnen erhalten. Dieses Protokoll, das aus Anforderungs- und Antwort-Nachrichtenformaten besteht, die auf XML beruhen, kann an viele verschiedene zugrunde liegende Übertragungs- und Transportprotokolle gebunden werden; SAML legt derzeit eine Bindung, die Bindung an SOAP über HTTP, fest. SAML-Instanzen können bei der Erstellung ihrer Antworten verschiedene Informationsquellen nutzen, so zum Beispiel externe Richtlinien-Speicher und Bestätigungen, die als Eingabe in Anforderungen empfangen wurden. Während Clients Bestätigungen immer verbrauchen, können SAML-Instanzen folglich sowohl Erzeuger als auch Verbraucher von Bestätigungen sein.
Die SAML-Spezifikation besagt, dass eine Bestätigung ein Informationspaket ist, das eine oder mehrere Aussagen liefert, die von einem Aussteller gemacht wurden. SAML ermöglicht Ausstellern, drei verschiedene Arten von Bestätigungsaussagen zu machen: Identitätsprüfung, bei der die Identität des angegebenen Subjekts zu einem bestimmten Zeitpunkt durch ein bestimmtes Mittel geprüft wurde; Berechtigungszuweisung, bei der einem Gesuch, dem angegebenen Subjekt den Zugriff auf die betreffende Ressource zu gewähren, stattgegeben oder das Gesuch abgelehnt wurde; und Attribut, bei dem das angegebene Subjekt den bereitgestellten Attributen zugeordnet wird. Wie nachstehend ausführlicher erörtert wird, können bei Bedarf verschiedene Bestätigungsformate in andere Bestätigungsformate umgesetzt werden.
Identitätsprüfung ist der Prozess, bei dem ein Satz von Zugangsdaten, die von einem Benutzer oder im Namen eines Benutzers bereitgestellt werden, auf Gültigkeit geprüft wird. Eine Identitätsprüfung wird durchgeführt, indem etwas, das ein Benutzer kennt, etwas, das ein Benutzer hat, oder etwas, das der Benutzer ist, d. h. irgendein physisches Merkmal des Benutzers, auf Gültigkeit geprüft wird. Zu dem, was ein Benutzer kennt, kann ein gemeinsames Geheimnis wie zum Beispiel das Passwort eines Benutzers oder der kryptografische Schlüssel eines Benutzers, der nur diesem Benutzer bekannt ist und der auf Gültigkeit geprüft wird, gehören. Das, was ein Benutzer hat, kann unter anderem eine Chipkarte oder ein Hardware-Token sein. Zu physischen Merkmalen des Benutzers könnte eine biometrische Eingabe wie zum Beispiel ein Fingerabdruck oder das Venen-Muster der Netzhaut gehören.
Ein Legitimationsnachweis ist ein Satz von Challenge/Response-(Zufallszahl/Antwort-)Daten, die in verschiedenen Identitätsprüfungsprotokollen verwendet werden. Eine Kombination aus Benutzername und Passwort stellt beispielsweise die bekannteste Art von Anmeldedaten dar. Andere Formen von Legitimationsnachweisen können verschiedene Formen von Challenge/Response-Daten, Public-Key-Infrastructure-(PKI-)Zertifikate, Chipkarten, biometrische Daten usw. beinhalten. Ein Legitimationsnachweis unterscheidet sich von einer Identitätsbestätigung: Ein Legitimationsnachweis wird von einem Benutzer als Teil einer Identitätsprüfungsprotokollfolge einem Identitätsprüfungsserver oder -dienst übergeben, und eine Identitätsbestätigung ist eine Aussage über die erfolgreiche Übergabe und Gültigkeitsprüfung der Anmeldedaten eines Benutzers, wobei diese Bestätigung bei Bedarf anschließend zwischen Einheiten übertragen wird.
Unterschiede zwischen Lösungen für eine Einmalanmeldung nach dem Stand der Technik
Wie zuvor erwähnt wurde, sind Lösungen für eine Einmalanmeldung nach dem Stand der Technik auf homogene Umgebungen beschränkt, in denen es zwischen beteiligten Unternehmen vorab getroffene Geschäftsvereinbarungen gibt. Diese Geschäftsvereinbarungen legen Vertrauensstellungen fest und definieren die sichere Übertragung von Daten zwischen Unternehmen. Zu diesen Geschäftsvereinbarungen gehören auch technische Vereinbarungen über Regeln, die festlegen, wie Benutzeridentitäten von einem Unternehmen in ein anderes Unternehmen umgesetzt oder abgebildet und wie die Daten übertragen werden, mittels derer unter beteiligten Unternehmen für Benutzer gebürgt wird.
Anders ausgedrückt, bei bisherigen Lösungen für eine Einmalanmeldung kann ein Unternehmen einer Identitätsbestätigung (zusammen mit der Identität des Benutzers, die in der Bestätigung bereitgestellt wird) trauen, die von einem anderen Unternehmen auf der Grundlage von vorab ausgehandelten oder vorab konfigurierten Vereinbarungen erzeugt wurde. Jedes einzelne Unternehmen weiß, wie Identitätsbestätigungen erzeugt und ausgewertet werden müssen, so dass diese für andere Unternehmen, die untereinander ähnliche Vereinbarungen getroffen haben, wie zum Beispiel Unternehmen, die elektronischen Handel im Internet betreiben, verständlich sind. Diese homogenen Umgebungen sind eng verbunden, da es eine den Unternehmen bekannte deterministische Beziehung gibt, um die Benutzer-Identitäten systemübergreifend abzubilden. Diese enge Verbindung ist aufgrund der Geschäftsvereinbarungen möglich, mittels derer die Einmalanmelde-Umgebung eingerichtet wird.
Das Verbundmodell
Im Zusammenhang mit dem World Wide Web erwarten Benutzer inzwischen die Möglichkeit, vom Dialog mit einer Anwendung in einer Internet-Domäne zum Dialog mit einer anderen Anwendung in einer anderen Domäne wechseln zu können, ohne sich groß um die Informationsbarrieren zwischen jeder einzelnen Domäne kümmern zu müssen. Benutzer würden sich gerne die lästigen Unannehmlichkeiten ersparen, die dadurch verursacht werden, dass sie für eine einzige Transaktion ihre Identität in mehreren Domänen nachweisen müssen. Anders ausgedrückt, Benutzer erwarten, dass Unternehmen zusammenarbeiten, möchten jedoch im Allgemeinen, dass Domänen ihren Wunsch nach Vertraulichkeit respektieren. Überdies möchten Benutzer die Anzahl der Domänen, die private Daten dauerhaft speichern, möglicherweise lieber begrenzen. Diese Erwartungen seitens der Benutzer werden in einer sich schnell entwickelnden heterogenen Umgebung gestellt, in der viele Unternehmen und Organisationen Verfahren zur Identitätsprüfung verkünden, die miteinander im Wettbewerb stehen.
Im Gegensatz zu Systemen nach dem Stand der Technik stellt die vorliegende Erfindung gemäß einer Ausführungsform ein Verbundmodell bereit, das es Unternehmen ermöglicht, einen Benutzer die Erfahrung einer Einmalanmeldung machen zu lassen. Anders ausgedrückt, die vorliegende Erfindung unterstützt vorzugsweise eine heterogene Verbundumgebung. Nochmals beispielhalber Bezug nehmend auf 1E kann der Benutzer 190 seine Identität gegenüber der Domäne 191 nachweisen und die Domäne 191 dann veranlassen, jeder nachgelagerten Domäne, die gegebenenfalls an einer Transaktion beteiligt ist, die entsprechenden Bestätigungen bereitzustellen. Diese nachgelagerten Domänen müssen Identitätsbestätigungen und/oder andere Arten von Bestätigungen verstehen und ihnen vertrauen können, obwohl es zwischen der Domäne 191 und diesen anderen nachgelagerten Domänen keine vorher festgelegten Bestätigungsformate gibt. Neben der Voraussetzung, dass sie diese Bestätigungen verstehen, müssen die nachgelagerten Domänen auch in der Lage sein, die in einer Bestätigung enthaltene Identität in eine Identität umzusetzen, die den Benutzer 190 in einer bestimmten Domäne darstellt, obgleich es keine vorher festgelegte Beziehung auf der Grundlage einer Identitätsabbildung gibt. Es sei jedoch angemerkt, dass die vorliegende Erfindung auf verschiedene Arten von Domänen anwendbar und nicht auf Domänen vom Typ ISP beschränkt ist, die in 1E als beispielhafte Domänen dargestellt sind.
Die vorliegende Erfindung bezieht sich vorzugsweise auf eine Verbundumgebung. Im Allgemeinen verfügt ein Unternehmen über seine eigene Registrierdatenbank für Benutzer und verwaltet Beziehungen mit seiner eigenen Gruppe von Benutzern. Jedes Unternehmen bedient sich gewöhnlich seiner eigenen Mittel, um die Identität dieser Benutzer nachzuweisen. Das Verbundschema der bevorzugten Ausführungsform ermöglicht Unternehmen jedoch, kollektiv zusammenzuarbeiten, so dass Benutzer in einem Unternehmen Beziehungen zu einer Gruppe von Unternehmen durch die Beteiligung eines Unternehmens an einem Unternehmensverbund vorteilhaft nutzen können. Benutzern kann der Zugriff auf Ressourcen in jedem der zu dem Verbund gehörenden Unternehmen so gewährt werden, als hätten sie eine direkte Beziehung zu jedem Unternehmen. Benutzer müssen sich weder bei jedem Unternehmen, das von Interesse ist, anmelden noch müssen sie sich ständig ausweisen und ihre Identität nachweisen. In dieser Verbundumgebung gibt ein Identitätsprüfungsschema einem Benutzer folglich die Möglichkeit, die Erfahrung einer Einmalanmeldung in den sich schnell entwickelnden heterogenen Umgebungen in der Informationstechnologie zu machen.
In der bevorzugten Ausführungsform stellt ein Verbund eine aus einzelnen Einheiten wie zum Beispiel Unternehmen, Organisationen, Institutionen usw. bestehende Gruppe dar, die zusammenarbeiten, um einem Benutzer die Möglichkeit zu geben, die Erfahrung einer bequemen Einmalanmeldung zu machen. In der bevorzugten Ausführungsform unterscheidet sich eine Verbundumgebung von einer typischen Einmalanmelde-Umgebung dahingehend, dass zwei Unternehmen keine direkte Beziehung zueinander haben müssen, die vorab hergestellt wurde und die festlegt, welche Daten über einen Benutzer in welcher Weise übertragen werden. In einer Verbundumgebung stellen Einheiten Dienste bereit, die sich mit der Prüfung der Identität von Benutzern, der Annahme von Identitätsbestätigungen, z. B. Authentifizierungstoken, die von anderen Einheiten übergeben werden, und der Bereitstellung einer bestimmten Form der Umsetzung der Identität desjenigen Benutzers, für den man sich verbürgt hat, in eine Identität, die innerhalb der lokalen Einheit verstanden wird, befassen.
Durch den Zusammenschluss zu einem Verbund verringert sich der Verwaltungsaufwand für Diensteanbieter. Ein Diensteanbieter kann sich auf seine Vertrauensbeziehungen in Bezug auf den Verbund als Ganzes verlassen; der Diensteanbieter braucht Daten zur Identitätsprüfung wie zum Beispiel Benutzerpasswort-Daten nicht zu verwalten, da er auf die Identitätsprüfung zurückgreifen kann, die von der für die Identitätsprüfung zuständigen Heimdomäne/dem Identitätsanbieter vorgenommen wurde.
Die vorliegende Erfindung betrifft vorzugsweise auch ein System zur Verwaltung von Verbundidentitäten, auf dessen Grundlage lose miteinander verbundene Dienste zur Identitätsprüfung, zur Benutzerregistrierung, zur Benutzerprofilverwaltung und/oder Dienste zur Berechtigungszuweisung über Sicherheitsdomänen hinweg zusammenarbeiten. Durch die Verwaltung von Verbundidentitäten können Dienste, die in ganz verschiedenen Sicherheitsdomänen beheimatet sind, sicher zusammenarbeiten, obgleich es in diesen völlig verschiedenen Domänen Unterschiede bei den zugrunde liegenden Sicherheitsmechanismen und Betriebssystem-Plattformen geben kann. Eine Einmalanmeldung erfolgt, sobald ein Benutzer seine Teilnahme an einem Verbund festlegt.
Heimdomäne oder Identitätsanbieter im Vergleich zu sich auf die Vertrauenswürdigkeit verlassende Domäne oder Diensteanbieter
Wie nachstehend ausführlicher erklärt wird, bietet die vorliegende Erfindung gemäß einer Ausführungsform deutliche Vorteile für den Benutzer. Die vorliegende Erfindung ermöglicht einem Benutzer vorzugsweise, seine Identität an einer ersten Einheit nachzuweisen, die nachstehend auch als die Heimdomäne des Benutzers, die für die Identitätsprüfung zuständige Heimdomäne des Benutzers oder als Identitätsanbieter des Benutzers bezeichnet wird. Diese erste Einheit kann die Funktion einer ausgebenden Partei haben, die eine Identitätsbestätigung des Benutzers ausgibt, welche zur Verwendung an einer zweiten Einheit vorgesehen ist, die wiederum als allgemeiner Diensteanbieter betrachtet werden kann. Der Benutzer kann dann auf geschützte Ressourcen an einer anderen zweiten Einheit, die als die sich auf die Vertrauenswürdigkeit verlassende Partei bezeichnet wird, zugreifen, indem er die Identitätsbestätigung übergibt, die von der ersten Einheit ausgegeben wurde, ohne dass er seine Identität an der zweiten Einheit, d. h. dem Diensteanbieter, ausdrücklich erneut nachweisen muss. Daten, die von einer ausgebenden Partei an eine sich auf die Vertrauenswürdigkeit verlassende Partei weitergereicht werden, haben die Form einer Bestätigung, und diese Bestätigung kann verschiedene Arten von Informationen in Form von Aussagen haben. Eine Bestätigung kann beispielsweise eine Aussage über die nachgewiesene Identität eines Benutzers oder eine Aussage über Benutzerattribut-Daten sein, die einem bestimmten Benutzer zugeordnet werden.
Nun Bezug nehmend auf 2A zeigt ein Blockschaltbild die Terminologie der Verbundumgebung in Bezug auf eine Transaktion, die von einem Benutzer eingeleitet wird und an ein erstes Verbundunternehmen gerichtet ist, das als Reaktion darauf Aktionen an nachgelagerten Einheiten innerhalb der Verbundumgebung aufruft. 2A zeigt, dass die Terminologie in Abhängigkeit von der Aussicht einer in dem Verbund befindlichen Einheit auf eine bestimmte Verbund-Operation abweichen kann. Im Einzelnen zeigt 2A, dass die vorliegende Erfindung vorzugsweise die Transitivität des Vertrauens und die Transitivität des Prozesses der Identitätsbestätigung unterstützt; eine Domäne kann eine Bestätigung auf der Grundlage ihres Vertrauens in eine Identität ausgeben, die von einer anderen Domäne bestätigt wurde. Der Benutzer 202 leitet eine Transaktion durch eine Anforderung für eine geschützte Ressource an einem Unternehmen 204 ein. Wenn die Identität des Benutzers 202 im Verlauf einer Transaktion vom Unternehmen 204 nachgewiesen wurde oder vom Unternehmen 204 schließlich nachgewiesen wird, ist das Unternehmen 204 für diese Verbundsitzung die Heimdomäne des Benutzers, d. h. der Identitätsanbieter des Benutzers. Unter der Annahme, dass die Transaktion eine bestimmte vom Unternehmen 206 durchzuführende Operation erfordert und das Unternehmen 204 eine Bestätigung an das Unternehmen 206 überträgt, ist das Unternehmen 204 in Bezug auf diese bestimmte Operation die ausgebende Domäne, und das Unternehmen 206 ist bei dieser Operation die sich auf die Vertrauenswürdigkeit verlassende Domäne; anders ausgedrückt, das Unternehmen 206 ist bei der aktuellen Transaktion der Diensteanbieter. Unter der Annahme, dass die Transaktion weitere Operationen erforderlich macht, zum Beispiel, dass das Unternehmen 206 eine Bestätigung an das Unternehmen 208 überträgt, ist das Unternehmen 206 in Bezug auf die angeforderte Operation die ausgebende Domäne, und das Unternehmen 208 ist bei dieser Operation die sich auf die Vertrauenswürdigkeit verlassende Domäne; in diesem Fall kann das Unternehmen 208 als ein weiterer nachgelagerter Diensteanbieter betrachtet werden, obgleich eine Verbundtransaktion gewöhnlich als eine Transaktion beschrieben werden kann, an der nur zwei Domänen beteiligt sind, der Identitätsanbieter und der Diensteanbieter.
In der Verbundumgebung der bevorzugten Ausführungsform wird die Domäne, gegenüber der der Benutzer seine Identität nachweist, als die (für die Identitätsprüfung zuständige) Heimdomäne des Benutzers oder als der Identitätsanbieter des Benutzers bezeichnet. Der Identitätsanbieter verwaltet die Anmeldedaten, die physisch vom Arbeitgeber des Benutzers, vom ISP des Benutzers oder von einer anderen gewerblich tätigen Einheit unterstützt werden können. Obwohl die Möglichkeit besteht, dass es in einer Verbundumgebung mehrere Unternehmen geben könnte, die als Heimdomäne des Benutzers dienen könnten, da es mehrere Unternehmen geben kann, die die Anmeldedaten eines Benutzers erzeugen und auf Gültigkeit prüfen können, kann eine Verbundtransaktion gewöhnlich als eine Transaktion beschrieben werden, an der nur ein einziger Identitätsanbieter beteiligt ist.
Aus der Sicht der Identitätsprüfung ist die ausgebende Partei einer Identitätsbestätigung gewöhnlich der Identitätsanbieter des Benutzers, d. h. die für die Identitätsprüfung zuständige Heimdomäne. Die Heimdomäne des Benutzers kann, muss aber nicht, persönliche Daten oder Profildaten für den Benutzer verwalten. Aus der Sicht der Attribute, die personenbezogene Daten, Personalisierungsdaten oder andere Benutzerattribute beinhalten, könnte folglich eine ausgebende Partei für eine Attribut-Bestätigung die Heimdomäne des Benutzers sein. Um Verwechslungen zu vermeiden, kann eine gesonderte Terminologie für Attribut-Heimdomänen und für Domänen, die für die Identitätsprüfung zuständig sind, verwendet werden, aber der nachstehend verwendete Begriff "Heimdomäne" kann so ausgelegt werden, dass er sich auf eine für die Identitätsprüfung zuständige Heimdomäne bezieht.
Im Rahmen einer bestimmten Verbundsitzung gibt es jedoch gewöhnlich nur eine einzige Domäne, die die Funktion des Identitätsanbieters des Benutzers übernimmt, und zwar die Heimdomäne des Benutzers. Sobald ein Benutzer seine Identität gegenüber dieser Domäne nachgewiesen hat, werden alle anderen Domänen oder Unternehmen in dem Verbund für die Dauer dieser Sitzung als bloße Diensteanbieter, d. h. als sich auf die Vertrauenswürdigkeit verlassende Parteien, behandelt.
Unter der Annahme, dass die bevorzugte Ausführungsform eine Verbund-Infrastruktur bereitstellt, um die bereits vorhandene Systeme erweitert werden können, während die Auswirkungen auf eine bestehende, nicht als Verbund organisierte Architektur so gering wie möglich gehalten werden, wird der Vorgang der Identitätsprüfung in der Heimdomäne eines Benutzers nicht unbedingt dadurch geändert, dass sich die Heimdomäne ebenfalls an einer Verbundumgebung beteiligen kann. Anders ausgedrückt, die Heimdomäne kann zwar in eine Verbundumgebung eingebunden werden, die gemäß der vorliegenden Erfindung ausgeführt ist, doch sollte der Benutzer während der Durchführung einer Identitätsprüfungsoperation in seiner Heimdomäne dieselbe Erfahrung wie als Endbenutzer machen. Es sei jedoch angemerkt, dass nicht alle Benutzer in einem bestimmten Unternehmen zwangsläufig an der Verbundumgebung teilnehmen.
Überdies wird die Anmeldung eines Benutzers, beispielsweise durch das Einrichten eines Benutzerkontos, nicht unbedingt dadurch geändert, dass die Heimdomäne ebenfalls an einer Verbundumgebung teilnehmen kann. Zum Beispiel kann ein Benutzer nach wie vor mittels eines älteren oder bereits schon existierenden Anmeldevorgangs, der unabhängig von einer Verbundumgebung ist, ein Konto bei einer Domäne anlegen. Anders ausgedrückt, das Anlegen eines Benutzerkontos bei einer Heimdomäne kann, muss aber nicht, die Festlegung von Kontendaten beinhalten, die verbundübergreifend gültig sind, zum Beispiel durch die Verwendung von Identitätsumsetzungsdaten. Wenn es jedoch nur eine Verbunddomäne gibt, die die Identität eines Benutzers feststellen kann, d. h., wenn es in dem Verbund nur eine einzige Domäne gibt, bei der der Benutzer angemeldet ist, dann würde man erwarten, dass diese Domäne die Funktion einer Heimdomäne oder eines Identitätsanbieters des Benutzers übernimmt, um seine Transaktionen in der gesamten Verbundumgebung zu unterstützen.
Wenn ein Benutzer mehrere mögliche Heimdomänen in einer Verbundumgebung hat, kann er über mehr als einen Eintrittspunkt in den Verbund eintreten. Anders ausgedrückt, der Benutzer kann bei mehreren Domänen, die die Funktion eines Identitätsanbieters für den Benutzer übernehmen können, Konten unterhalten, und diese Domänen verfügen nicht zwangsläufig über Informationen über die anderen Domänen und auch nicht über die Identität des Benutzers in den anderen Domänen.
Während die Domäne, gegenüber der der Benutzer seine Identität nachweist, als die Heimdomäne des Benutzers oder als der Identitätsanbieter des Benutzers bezeichnet wird, ist die ausgebende Domäne eine Verbundeinheit, die eine Bestätigung zur Verwendung durch eine andere Domäne, zum Beispiel die sich auf die Vertrauenswürdigkeit verlassende Domäne, ausgibt. Gewöhnlich, aber nicht zwangsläufig ist die ausgebende Domäne die Heimdomäne oder der Identitätsanbieter des Benutzers. Daher ist es gewöhnlich so, dass die ausgebende Partei die Identität des Benutzers durch die üblichen Authentifizierungsprotokolle nachgewiesen hat, wie vorstehend erwähnt wurde. Es ist jedoch möglich, dass die ausgebende Partei zuvor die Funktion einer sich auf die Vertrauenswürdigkeit verlassenden Partei hatte, wodurch sie eine Bestätigung von einer anderen ausgebenden Partei empfangen hat. Anders ausgedrückt, da sich eine von einem Benutzer eingeleitete Transaktion in einer Verbundumgebung durch eine Reihe von Unternehmen ziehen kann, kann eine empfangende Partei bei einer nachgelagerten Transaktion anschließend die Funktion einer ausgebenden Partei übernehmen. Im Allgemeinen kann jede Domäne, die im Namen eines Benutzers Identitätsbestätigungen ausgeben kann, die Funktion einer ausgebenden Domäne übernehmen.
Die sich auf die Vertrauenswürdigkeit verlassende Domäne ist eine Domäne, die eine Bestätigung von einer ausgebenden Partei erhält. Die sich auf die Vertrauenswürdigkeit verlassende Partei kann eine Bestätigung, die von einer dritten Partei im Namen des Benutzers, d. h. von der ausgebenden Domäne, ausgegeben wird, annehmen, ihr vertrauen und sie verstehen. Im Allgemeinen ist es die Pflicht der sich auf die Vertrauenswürdigkeit verlassenden Domäne, eine geeignete Identitätsprüfungsstelle in Anspruch zu nehmen, um eine Identitätsbestätigung auszuwerten. Überdies ist es möglich, dass die sich auf die Vertrauenswürdigkeit verlassende Partei die Identität eines bestimmten Benutzers nachweisen kann, d. h. die Funktion einer Heimdomäne oder eines Identitätsanbieters eines Benutzers übernehmen kann, aber es ist gleichfalls möglich, dass eine sich auf die Vertrauenswürdigkeit verlassende Partei nicht in der Lage ist, die Identität einen bestimmten Benutzers mit herkömmlichen Verfahren nachzuweisen. Folglich ist eine sich auf die Vertrauenswürdigkeit verlassende Partei eine Domäne oder ein Unternehmen, die beziehungsweise das sich auf die Identitätsbestätigung verlässt, die von einem Benutzer übergeben wird und einem Benutzer die Möglichkeit gibt, die Erfahrung einer Einmalanmeldung zu machen, statt den Benutzer als Teil einer interaktiven Sitzung mit ihm zur Eingabe seiner Anmeldedaten aufzufordern.
Verbundarchitektur – vorgeschaltetes Verbundverarbeitungssystem für ältere Systeme
Nun Bezug nehmend auf 2B zeigt ein Blockschaubild die Einbindung von Systemen, die in einer bestimmten Domäne bereits vorhanden sind, in einige der Komponenten der Verbundarchitektur der vorliegenden Erfindung gemäß einer Ausführungsform der vorliegenden Erfindung. Eine Verbundumgebung enthält Verbundeinheiten, die Benutzern viele verschiedene Dienste bereitstellen. Der Benutzer 212 kommuniziert interaktiv mit der Client-Einheit 214, die die Browser-Anwendung 216 und verschiedene andere Client-Anwendungen 218 unterstützen kann. Der Benutzer 212 unterscheidet sich von der Client-Einheit 214, dem Browser 216 oder einer anderen Software, die als Schnittstelle zwischen dem Benutzer und anderen Einheiten und Diensten dient. In der folgenden Beschreibung wird in manchen Fällen gegebenenfalls zwischen dem Benutzer, der eindeutig in einer Client-Anwendung agiert, und einer Client-Anwendung, die im Namen des Benutzers tätig ist, unterschieden. Im Algemeinen ist ein Anforderer jedoch ein zwischengeschalteter Dritter wie zum Beispiel eine clientbasierte Anwendung, ein Browser, ein SOAP-Client usw., bei dem davon ausgegangen werden kann, dass er im Namen des Benutzers tätig ist.
Die Browser-Anwendung 216 kann ein üblicher Browser wie beispielsweise ein in mobilen Einheiten installierter Browser sein, der viele Module wie eine HTTP-Übertragungskomponente 220 und ein Markup-Language-(ML-)Übersetzungsprogramm 222 umfasst. Die Browser-Anwendung 216 kann auch Zusatzprogramme (plug-ins) wie einen Client 224 für Webdienste und/oder herunterladbare Applets, die gegebenenfalls eine Laufzeitumgebung für virtuelle Maschinen erforderlich machen, unterstützen. Der Client 224 für Webdienste kann das Simple Object Access Protocol (SOAP) verwenden, bei dem es sich um ein leichtgewichtiges Protokoll zur Festlegung des Austauschs von strukturierten und typisierten Daten in einer dezentralisierten verteilten Umgebung handelt. SOAP ist ein auf XML beruhendes Protokoll, das aus drei Teilen besteht: einem Umschlag, der ein Rahmenwerk festlegt, um zu beschreiben, was eine Nachricht ist und wie sie verarbeitet werden soll; einem Satz von Codierregeln, um Instanzen von Datentypen, die von der Anwendung festgelegt werden, auszudrücken; und Regeln zur Darstellung von Fernprozeduraufrufen und Antworten auf Fernprozeduraufrufe. Der Benutzer 212 kann zum einen mit Hilfe der Anwendung 216 auf webbasierte Dienste zugreifen, aber er kann auch über andere Clients für Webdienste, die sich auf der Client-Einheit 214 befinden, auf Webdienste zugreifen. Ein paar der in den folgenden Figuren gezeigten Beispiele führen eine HTTP-Umleitung über den Browser des Benutzers durch, um Daten zwischen Einheiten in einer Verbundumgebung auszutauschen. Es sei jedoch angemerkt, dass die vorliegende Erfindung über viele verschiedene Übertragungsprotokolle abgewickelt werden kann und nicht auf Übertragungen beschränkt ist, die auf HTTP beruhen. Die Einheiten in der Verbundumgebung können bei Bedarf zum Beispiel direkt kommunizieren; Nachrichten müssen nicht durch den Browser des Benutzers umgeleitet werden.
Gemäß einer Ausführungsform kann die vorliegende Erfindung so realisiert werden, dass für eine Verbundumgebung erforderliche Komponenten in bereits vorhandene Systeme eingebunden werden können. 2B zeigt eine Ausführungsform, die es ermöglicht, diese Komponenten in einer Weise zu realisieren, dass sie einem bereits vorhandenen System vorgeschaltet werden können. Die bereits vorhandenen Komponenten in einer Verbunddomäne können als ältere Anwendungen oder nachgeschaltete (Backend-)Verarbeitungskomponenten 230, zu denen auch die Authentication-Service-Runtime-(ASR-)Server 232 gehören, betrachtet werden, und zwar in einer Weise, die ähnlich der in 2C. gezeigten ist. Die ASR-Server 232 sind für die Identitätsprüfung von Benutzern zuständig, wenn die Domäne den Zugriff auf die Anwendungsserver 234 steuert, die als Server betrachtet werden können, welche geschützte Ressourcen 235 erzeugen, abrufen oder in anderer Weise unterstützen oder verarbeiten. Die Domäne kann weiterhin die ältere Anwendung 236 zur Benutzeranmeldung verwenden, um Benutzer für den Zugriff auf Anwendungsserver 234 anzumelden. Daten, die zur Prüfung der Identität eines angemeldeten Benutzers notwendig sind, werden in der älteren Benutzer-Registrierdatenbank 238 gespeichert.
Nach der Aufnahme in die Verbundumgebung kann die Domäne weiterhin arbeiten, ohne dass Verbundkomponenten eingreifen müssen. Anders ausgedrückt, die Domäne kann so konfiguriert werden, dass Benutzer direkt auf bestimmte Anwendungsserver oder andere geschützte Ressourcen zugreifen können, ohne den weg über einen Kontaktserver oder über eine andere Komponente, die die Funktionalität dieses Kontaktservers umsetzt, nehmen zu müssen; ein Benutzer, der auf diese Weise auf ein System zugreift, würde die typischen Datenflüsse zur Identitätsprüfung wahrnehmen und einen ganz gewöhnlichen Zugriff erleben. Dabei könnte ein Benutzer, der direkt auf das ältere System zugreift, jedoch keine Verbundsitzung aufbauen, die dem Kontaktserver der Domäne bekannt wäre.
Die älteren Funktionen der Domäne können durch die Verwendung einer vorgeschalteten Verbundverarbeitung 240, die den Kontaktserver 242 und den vertrauenswürdigen Proxy-Server 244 (oder, einfacher ausgedrückt, den vertrauenswürdigen Proxy 244 oder den vertrauenswürdigen Dienst 244) einschließt, welcher selbst interaktiv mit dem Sicherheitstoken-Dienst (Security Token Service (STS)) 245 kommuniziert, zusammen mit dem Server/Dienst 246 zur Verwaltung des Lebenszyklus des Benutzers im Verbund, die alle nachstehend mit Bezug auf 2C ausführlicher beschrieben werden, in eine Verbundumgebung eingebunden werden. Die Verbundkonfigurationsanwendung 247 ermöglicht einem als Administrator tätigen Benutzer, die vorgeschalteten (Frontend-)Verbundkomponenten so zu konfigurieren, dass sie über die Verbundschnittstelleneinheit 248 mit den älteren nachgeschalteten (Backend-)Komponenten verbunden werden können.
Ältere oder in einem bestimmten Unternehmen bereits vorhandene Identitätsprüfungsdienste können verschiedene bekannte Identitätsprüfungsverfahren oder -Token wie zum Beispiel aus Benutzername und Passwort bestehende Informationen oder auf einem Chipkarten-Token beruhende Informationen verwenden. Bei der vorliegenden Erfindung kann die Funktionalität eines älteren Identitätsprüfungsdienstes vorzugsweise jedoch durch den Einsatz von Kontaktservern in einer Verbundumgebung genutzt werden. Die Benutzer können zwar weiterhin direkt auf ältere Identitätsprüfungsserver zugreifen, ohne über einen Kontaktserver gehen zu müssen, doch würde ein Benutzer, der auf diese Weise auf ein System zugreift, die typischen Identitätsprüfungs-Datenflüsse und einen typischen Zugriff erfahren; gemäß einer Ausführungsform der vorliegenden Erfindung wäre es einem Benutzer, der direkt auf ein älteres Identitätsprüfungssystem zugreifen würde, nicht möglich, eine Verbund-Identitätsbestätigung als Identitätsnachweis zu erzeugen. Eine der Aufgaben des vorgeschalteten Verbundverarbeitungssystems besteht darin, ein an einem Kontaktserver empfangenes Verbundidentitätsprüfungs-Token in ein für den älteren Identitätsprüfungsdienst verständliches Format umzusetzen. Folglich müsste ein Benutzer, der über den Kontaktserver auf die Verbundumgebung zugreift, seine Identität dem älteren Identitätsprüfungsdienst gegenüber nicht unbedingt erneut nachweisen. Vorzugsweise würde die Identität des Benutzers einem älteren Identitätsprüfungsdienst gegenüber durch eine Kombination aus dem Kontaktserver und einem vertrauenswürdigen Proxy nachgewiesen werden, so dass es den Anschein hat, als ob der Benutzer an einem Dialog zur Identitätsprüfung beteiligt wäre.
Verbundarchitektur – Kontaktserver, vertrauenswürdige Proxys und vertrauenswürdige Vermittler
Nun Bezug nehmend auf 2C zeigt ein Blockschaubild eine Verbundarchitektur gemäß einer Ausführungsform der vorliegenden Erfindung. Eine Verbundumgebung enthält Verbundunternehmen oder ähnliche Einheiten, die Benutzern viele verschiedene Dienste bereitstellen. Ein Benutzer kann über eine Anwendung auf einer Client-Einheit versuchen, auf Ressourcen in verschiedenen Einheiten wie zum Beispiel im Unternehmen 250 zuzugreifen. Ein Kontaktserver in jedem Verbundunternehmen, zum Beispiel der Kontaktserver (point-of-contact (POC) server) 252 im Unternehmen 250, ist der Eintrittspunkt des Benutzers in die Verbundumgebung. Der Kontaktserver hält die Auswirkungen auf vorhandene Komponenten, z. B. auf ältere Systeme, in einer bereits bestehenden, nicht als Verbund organisierten Architektur so gering wie möglich, da der Kontaktserver viele der Verbundanforderungen abwickelt. Der Kontaktserver ermöglicht die Verwaltung von Sitzungen und die Umwandlung von Protokollen, und er leitet möglicherweise eine Identitätsprüfung und/oder eine Umwandlung von Attributbestätigungen ein. Der Kontaktserver kann beispielsweise HTTP- oder HTTPS-Nachrichten in SOAP-Nachrichten umsetzen und umgekehrt. Wie nachstehend ausführlicher erklärt wird, kann der Kontaktserver auch zum Aufrufen eines vertrauenswürdigen Proxy verwendet werden, um Bestätigungen umzusetzen, beispielsweise kann ein von einer ausgebenden Partei empfangenes SAML-Token in ein für eine empfangende Partei verständliches Kerberos-Token umgesetzt werden.
Ein vertrauenswürdiger Poxy (ein vertrauenswürdiger Proxy-Server oder ein vertrauenswürdiger Dienst) wie zum Beispiel der vertrauenswürdige Proxy (TP) 254 im Unternehmen 250 stellt eine Vertrauensbeziehung zwischen zwei Einheiten in einem Verbund her und verwaltet diese Beziehung. Ein vertrauenswürdiger Proxy ist im Allgemeinen in der Lage, ein Identitätsprüfungs-Token aus einem Format, das von der ausgebenden Partei verwendet wird, in ein für die empfangende Partei verständliches Format umzusetzen (mittels des Sicherheitstoken-Dienstes, der nachstehend ausführlicher beschrieben wird).
Durch die gemeinsame Verwendung eines Kontaktservers und eines vertrauenswürdigen Proxy werden die Auswirkungen, die die Realisierung einer Verbundarchitektur auf eine bereits vorhandene, nicht als Verbund organisierte Gruppe von Systemen hat, so gering wie möglich gehalten. Folglich erfordert die Verbundarchitektur der vorliegenden Erfindung vorzugsweise die Realisierung von mindestens einem Kontaktserver und mindestens einem vertrauenswürdigen Proxy je Verbundeinheit, ungeachtet dessen, ob es sich bei der Einheit um ein Unternehmen, eine Domäne oder eine andere logische oder physische Einheit handelt. Die Verbundarchitektur einer Ausführungsform der vorliegenden Erfindung macht jedoch nicht zwingend Änderungen an der vorhandenen, nicht zum Verbund gehörenden Gruppe von Systemen erforderlich. Vorzugsweise gibt es einen einzigen vertrauenswürdigen Proxy für eine bestimmte Verbundeinheit, obgleich es aus Gründen der Verfügbarkeit mehrere vertrauenswürdige Proxys geben kann, oder es kann mehrere vertrauenswürdige Proxys für viele verschiedene kleinere Einheiten innerhalb einer Verbundeinheit, zum Beispiel für einzelne Tochtergesellschaften innerhalb eines Unternehmens, geben. Es besteht die Möglichkeit, dass eine bestimmte Einheit zu mehr als einem Verbund gehören kann, wenngleich dieses Szenario nicht unbedingt mehrere vertrauenswürdige Proxys erforderlich machen würde, da ein einziger vertrauenswürdiger Proxy Vertrauensbeziehungen innerhalb von mehreren Verbunden verwalten könnte.
Eine Aufgabe eines vertrauenswürdigen Proxy kann darin bestehen, den Typ von Token, den eine andere Domäne benötigt, und/oder den vertrauenswürdigen Proxy in dieser Domäne zu ermitteln beziehungsweise für diese Ermittlung zuständig zu sein. Ein vertrauenswürdiger Proxy ist in der Lage oder dafür verantwortlich, ein Identitätsprüfungs-Token aus einem Format, das von der ausgebenden Partei verwendet wird, in ein für die empfangende Partei verständliches Format umzusetzen. Der vertrauenswürdige Proxy 254 kann auch für die Umsetzung der Benutzeridentität oder für die Umsetzung von Attributen verantwortlich sein, welche für das Unternehmen 250 vorgenommen werden muss. Überdies kann ein vertrauenswürdiger Proxy die Vergabe von Alias-Namen als stellvertretende Bezeichnungen einer Benutzer-Identität unterstützen, die einen Benutzer eindeutig ausweisen, ohne zusätzliche Informationen über die Identität des Benutzers in der Realität zu geben. Ferner kann ein vertrauenswürdiger Proxy Identitätsprüfungs- und/oder Sitzungszugangsdaten zur Verwendung durch den Kontaktserver ausgeben. Ein vertrauenswürdiger Proxy kann jedoch einen vertrauenswürdigen Vermittler aufrufen und um Hilfe bitten, wie nachstehend ausführlicher beschrieben wird. Eine Identitätsumsetzung kann erforderlich sein, um die Identität sowie Attribute eines Benutzers, die einer ausgebenden Partei bekannt sind, in eine Identität abzubilden, die für eine empfangende Partei aussagekräftig ist. Diese Umsetzung kann entweder von einem vertrauenswürdigen Proxy in einer ausgebenden Domäne, einem vertrauenswürdigen Proxy in einer empfangenden Domäne oder von beiden aufgerufen werden.
Der vertrauenswürdige Proxy 254 kann eine in ihn integrierte Komponente enthalten (oder mit dieser interaktiv kommunizieren), die als die Sicherheitstoken-Dienst-(STS-)Komponente 255 gezeigt ist, welche eine Token-Umsetzung ermöglicht sowie die Identitätsprüfungsdienst-Laufzeitkomponenten (authentication service runtime (ASR)) 256 aufruft, um Token zu erzeugen und auf Gültigkeit zu prüfen. Der Sicherheitstoken-Dienst stellt die von dem vertrauenswürdigen Proxy benötigten Dienste in Form der Ausgabe und Gültigkeitsprüfung von Token bereit, wobei diese Dienste auch die Identitätsumsetzung beinhalten können. Der Sicherheitstoken-Dienst beinhaltet daher eine Schnittstelle zu bestehenden Identitätsprüfungsdienst-Laufzeitkomponenten, oder er integriert diese Identitätsprüfungsdienst-Laufzeitkomponenten in den Dienst selbst. Statt in den vertrauenswürdigen Proxy integriert zu werden, kann die Sicherheitstoken-Dienst-Komponente auch als eine eigenständige Komponente ausgeführt werden, beispielsweise, um von dem vertrauenswürdigen Proxy aufgerufen zu werden, oder sie kann in einen Transaktionsserver, zum Beispiel als Teil eines Anwendungsservers, integriert werden.
Eine STS-Komponente kann beispielsweise eine Anforderung für die Ausgabe eines Kerberos-Token empfangen. Als Teil der Daten zur Identitätsprüfung des Benutzers, für den das Token erzeugt werden soll, kann die Anforderung ein binäres Token enthalten, das einen Benutzernamen und ein Passwort enthält. Die STS-Komponente vergleicht den Benutzernamen und das Passwort beispielsweise mit einer LDAP-Laufzeit (übliche Identitätsprüfung), um sie auf Gültigkeit zu prüfen, und ruft ein Kerberos-Schlüsselverteilungszentrum (Key Distribution Center (KDC)) auf, um ein Kerberos-Ticket für diesen Benutzer zu erzeugen. Dieses Token wird an den vertrauenswürdigen Proxy zur Verwendung innerhalb des Unternehmens zurückgeschickt; diese Verwendung kann jedoch eine Verlagerung des Token nach außen einschließen, damit es in eine andere Domäne in dem Verbund übertragen werden kann.
Ähnlich der in Bezug auf 1D beschriebenen Weise möchte ein Benutzer vielleicht auf Ressourcen in mehreren Unternehmen innerhalb einer Verbundumgebung, beispielsweise dem Unternehmen 250 und dem Unternehmen 260, zugreifen. Ähnlich wie vorstehend beim Unternehmen 250 beschrieben wurde, umfasst das Unternehmen 260 einen Kontaktserver 262, einen vertrauenswürdigen Proxy 264, den Sicherheitstoken-Dienst 265 und die Identitätsprüfungsdienst-Laufzeitkomponente 266. Zwar kann der Benutzer einzelne Transaktionen mit jedem Unternehmen direkt einleiten, doch leitet er vielleicht eine Transaktion mit dem Unternehmen 250 ein, die sich durch die gesamte Verbundumgebung zieht. Das Unternehmen 250 erfordert gegebenenfalls eine Zusammenarbeit mit mehreren anderen Unternehmen innerhalb der Verbundumgebung wie zum Beispiel dem Unternehmen 260, um eine bestimmte Transaktion durchzuführen, obwohl sich der Benutzer dieser Notwendigkeit vielleicht nicht bewusst war, als er eine Transaktion eingeleitet hatte. Das Unternehmen 260 wird als nachgelagerte Domäne einbezogen, und vorzugsweise erlaubt die vorliegende Erfindung erlaubt dem Unternehmen 250, dem Unternehmen 260 bei Bedarf eine Verbundbestätigung zu übergeben, um die Transaktion des Benutzers zu unterstützen.
Es kann vorkommen, dass ein vertrauenswürdiger Proxy nicht weiß, wie er das Authentifizierungstoken deuten soll, das er von einem zugehörigen Kontaktserver empfangen hat, und/oder wie er eine bestimmte Benutzeridentität und Attribute umsetzen soll. In diesem Fall zieht es der vertrauenswürdige Proxy vielleicht vor, die Funktionen auf einer vertrauenswürdigen Vermittlerkomponente wie beispielsweise dem Vermittler 268 aufzurufen. Ein vertrauenswürdiger Vermittler unterhält Beziehungen zu einzelnen vertrauenswürdigen Proxys und erzeugt dadurch ein transitives Vertrauen zwischen vertrauenswürdigen Proxys. Die Verwendung eines vertrauenswürdigen Vermittlers ermöglicht jeder Einheit innerhalb einer Verbundumgebung wie zum Beispiel den Unternehmen 250 und 260, eine Vertrauensbeziehung zu dem vertrauenswürdigen Vermittler herzustellen, statt mehrere einzelne Vertrauensbeziehungen zu jeder Domäne in der Verbundumgebung herzustellen. Wenn das Unternehmen 260 zum Beispiel bei einer vom Benutzer am Unternehmen 250 eingeleiteten Transaktion als nachgelagerte Domäne einbezogen wird, kann dem vertrauenswürdigen Proxy 254 am Unternehmen 250 versichert werden, dass eine Bestätigung von dem vertrauenswürdigen Proxy 254 für den vertrauenswürdigen Proxy 264 am Unternehmen 260 verständlich ist, wenn er den vertrauenswürdigen Broker 268 bei Bedarf um Hilfe ersucht. Zwar zeigt 2C die Verbundumgebung mit nur einem einzigen vertrauenswürdigen Vermittler, doch kann eine Verbundumgebung mehrere vertrauenswürdige Vermittler haben.
Es sei auch darauf hingewiesen, dass 2C zwar einen Kontaktserver 252, einen vertrauenswürdigen Proxy 254, die Sicherheitstoken-Dienst-Komponente 255 und die Identitätsprüfungsdienst-Laufzeitkomponente 256 als getrennte Einheiten zeigt, diese Komponenten jedoch nicht auf gesonderten Einheiten realisiert werden müssen. Es ist beispielsweise möglich, die Funktionen dieser einzelnen Komponenten in Form von Anwendungen auf einer einzigen physischen Einheit oder als zu einer einzigen Anwendung zusammengefasste Funktionen zu realisieren. Darüber hinaus zeigt 2C einen einzigen Kontaktserver, einen einzigen vertrauenswürdigen Proxy und einen einzigen Sicherheitstoken-Server für ein Unternehmen, doch kann eine alternative Konfiguration mehrere Kontaktserver, mehrere vertrauenswürdige Proxys und mehrere Sicherheitstoken-Server für jedes Unternehmen enthalten. Der Kontaktserver, der vertrauenswürdige Proxy, der Sicherheitstoken-Dienst und andere Verbundeinheiten können in unterschiedlicher Form wie zum Beispiel als Software-Anwendungen, Objekte, Module, Software-Bibliotheken usw. realisiert werden.
Ein vertrauenswürdiger Proxy/STS kann viele verschiedene Anmeldedaten annehmen und auf Gültigkeit prüfen, unter anderem herkömmliche Anmeldedaten wie zum Beispiel Kombinationen aus Benutzername und Passwort und Kerberos-Tickets sowie Authentifizierungstoken-Formate in einem Verbundsystem, die von einer dritten Partei erzeugte Authentifizierungstoken einschließen. Ein vertrauenswürdiger Proxy/STS kann die Annahme eines Authentifizierungstoken als ein andernorts erfolgter Identitätsnachweis zulassen. Dieses Authentifizierungstoken wird von ein ausgebenden Partei erzeugt und dient zur Angabe, dass ein Benutzer seine Identität bereits dieser ausgebenden Partei gegenüber nachgewiesen hat. Die ausgebende Partei erzeugt das Authentifizierungstoken als ein Mittel zur Bestätigung der geprüften Identität eines Benutzers. Ein vertrauenswürdiger Proxy/STS kann auch Attribut-Token oder Token verarbeiten, die verwendet werden, um Übertragungssitzungen oder Datenaustauschoperationen sicher zu machen wie zum Beispiel solche Token, die verwendet werden, um Sitzungsdaten in ähnlicher Weise wie eine SSL-Sitzungskennung zu verwalten.
Ein Sicherheitstoken-Dienst ruft bei Bedarf eine Identitätsprüfungsdienst-Laufzeitkomponente auf. Die Identitätsprüfungsdienst-Laufzeitkomponente unterstützt einen Identitätsprüfungsdienst, der die Identität eines Benutzers prüfen kann. Der Identitätsprüfungsdienst übernimmt die Funktion einer Identitätsprüfungsstelle, die Hinweise auf erfolgreiche oder fehlgeschlagene Versuche des Identitätsnachweises mittels Antworten zur Identitätsprüfung gibt. Der vertrauenswürdige Proxy/STS kann einen Identitätsprüfungsdienst nach innen verlagern, beispielsweise ein Szenario, bei dem es eine brandneue Installation eines Webdienstes gibt, der nicht mit einer bereits vorhandenen älteren Infrastruktur in Dialogverkehr treten muss. Andernfalls ruft die STS-Komponente externe Identitätsprüfungsdienste zur Gültigkeitsprüfung von Authentifizierungstoken auf. Die STS-Komponente könnte beispielsweise ein binäres Token "entpacken", das einen Benutzernamen/Passwort enthält, und dann mittels eines LDAP-Dienstes auf eine Benutzer-Registrierdatenbank zugreifen, um die übergebenen Anmeldedaten auf Gültigkeit zu prüfen.
Wenn die STS-Komponente von einer anderen Komponente wie zum Beispiel einem Anwendungsserver verwendet wird, kann sie zur Erzeugung von Token genutzt werden, die für eine Einmalanmeldung an älteren Identitätsprüfungssystemen erforderlich sind. Folglich kann die STS-Komponente für eine Umsetzung von Token zu internen Zwecken, d. h. innerhalb eines Unternehmens, und zu externen Zwecken, d. h. unternehmensübergreifend in einem Verbund, verwendet werden. Als ein Beispiel für einen internen Zweck kann ein Web-Anwendungsserver über einen CICS^®-(Customer-Information-Control-System-)Transaktionsverbindungsrechner (gateway) von IBM^® (IBM und CICS sind eingetragene Warenzeichen der International Business Machines Corporation) mit einem Großrechner verbunden werden; CICS ist eine Familie von Anwendungsservern und Verbindungselementen, die eine Online-Transaktionsverwaltung und Anschlussmöglichkeiten für aufgabenkritische Anwendungen auf Unternehmensebene vorsieht. Der Web-Anwendungsserver kann die STS-Komponente aufrufen, um ein Kerberos-Ticket (das von dem Web-Anwendungsserver intern verwendet wird) in ein IBM-RACF^®-Passticket umzusetzen, das von dem CICS-Transaktionsverbindungsrechner benötigt wird.
Die in 2C gezeigten Einheiten können mit Hilfe der vorstehend eingeführten Terminologie, z. B. "ausgebende Partei" und "sich auf die Vertrauenswürdigkeit verlassende Partei" oder "Identitätsanbieter" und "Diensteanbieter", erklärt werden. Als Teil des Herstellens und Unterhaltens von Vertrauensbeziehungen kann der vertrauenswürdige Proxy eines Identitätsanbieters festlegen, welche Arten von Token vom vertrauenswürdigen Proxy eines Diensteanbieters benötigt/angenommen werden. Folglich können vertrauenswürdige Proxys diese Informationen nutzen, wenn sie Token-Dienste von einem Sicherheitstoken-Dienst aufrufen. Wenn der vertrauenswürdige Proxy eines Identitätsanbieters eine Identitätsbestätigung für einen Diensteanbieter erzeugen muss, ermittelt der vertrauenswürdige Proxy die Art des benötigten Token und fordert das entsprechende Token von dem Sicherheitstoken-Dienst an.
Wenn der vertrauenswürdige Proxy eines Diensteanbieters eine Identitätsbestätigung von einem Identitätsanbieter empfängt, weiß der vertrauenswürdige Proxy, welche Art von Bestätigung er erwartet und welche Art von Bestätigung zur internen Verwendung im Diensteanbieter er benötigt. Der vertrauenswürdige Proxy des Diensteanbieters ersucht den Sicherheitstoken-Dienst um die Erzeugung der benötigten Token zur internen Verwendung auf der Grundlage der empfangenen Identitätsbestätigung.
Beide vertrauenswürdige Proxys und vertrauenswürdige Vermittler sind in der Lage, eine von einem Identitätsanbieter empfangene Bestätigung in ein für einen Diensteanbieter verständliches Format umzusetzen. Der vertrauenswürdige Vermittler kann das Bestätigungsformat (oder die Bestätigungsformate) für jeden der vertrauenswürdigen Proxys auswerten, mit denen er eine direkte Vertrauensbeziehung unterhält, wodurch es dem vertrauenswürdigen Vermittler möglich ist, eine Umsetzung von Bestätigungen zwischen einem Identitätsanbieter und einem Diensteanbieter vorzunehmen.
Diese Umsetzung kann von sowohl der einen als auch der anderen Partei über ihren lokalen vertrauenswürdigen Proxy angefordert werden. Folglich kann der vertrauenswürdige Proxy des Identitätsanbieters eine Umsetzung einer Bestätigung anfordern, bevor sie an den Diensteanbieter gesendet wird. Ebenso kann der vertrauenswürdige Proxy des Diensteanbieters eine Umsetzung einer Bestätigung anfordern, die von einem Identitätsanbieter empfangen wurde.
Eine Umsetzung von Bestätigungen umfasst die Umsetzung der Benutzeridentität, die Umsetzung der Identitätsbestätigung, die Umsetzung der Attributbestätigung beziehungsweise andere Formen von Bestätigungsumsetzungen. Den vorstehenden Punkt nochmals wiederholend, wird die Umsetzung von Bestätigungen von den vertrauenswürdigen Komponenten in einem Verbund, d. h. von vertrauenswürdigen Proxys und vertrauenswürdigen Vermittlern, durchgeführt. Ein vertrauenswürdiger Proxy kann die Umsetzung lokal vornehmen, entweder am Identitätsanbieter oder am Diensteanbieter, oder er kann Hilfe von einem vertrauenswürdigen Vermittler anfordern.
Unter der Annahme, dass ein Identitätsanbieter und ein Diensteanbieter bereits eigene Vertrauensbeziehungen zu einem vertrauenswürdigen Vermittler unterhalten, kann der vertrauenswürdige Vermittler bei Bedarf neue Vertrauensbeziehungen zwischen ausgebenden Parteien und Parteien, die sich auf die Vertrauenswürdigkeit verlassen, dynamisch erzeugen, d. h. vermitteln. Im Anschluss an die zunächst erfolgende Operation in Form der Vermittlung einer Vertrauensbeziehung, die von dem vertrauenswürdigen Vermittler durchgeführt wird, können der Identitätsanbieter und der Diensteanbieter die Beziehung direkt unterhalten, so dass der vertrauenswürdige Vermittler bei zukünftigen Umsetzungserfordernissen nicht aufgerufen werden muss. Es sei angemerkt, dass die Umsetzung von Authentifizierungstoken an drei möglichen Orten stattfinden kann: am vertrauenswürdigen Proxy des Identitätsanbieters, am vertrauenswürdigen Proxy des Diensteanbieters und am vertrauenswürdigen Vermittler. Vorzugsweise erzeugt der vertrauenswürdige Proxy des Identitätsanbieters eine Identitätsbestätigung, die von dem vertrauenswürdigen Vermittler verstanden wird, damit sie an den Diensteanbieter gesendet werden kann. Der Diensteanbieter ersucht dann den vertrauenswürdigen Vermittler um eine Umsetzung dieses Token in ein für den Diensteanbieter erkennbares Format. Die Umsetzung von Token kann vor der Übertragung, nach der Übertragung oder sowohl vor als auch nach der Übertragung der Identitätsbestätigung stattfinden.
Vertrauensbeziehungen innerhalb einer Verbundarchitektur
Innerhalb einer Verbundumgebung, die gemäß einer Ausführungsform der vorliegenden Erfindung realisiert wird, gibt es zwei Arten von "vertrauenswürdigen Domänen", die verwaltet werden müssen: Vertrauenswürdige Unternehmensdomänen und vertrauenswürdige Verbunddomänen. Die Unterschiede zwischen diesen beiden Arten von vertrauenswürdigen Domänen beruhen zum Teil auf den Geschäftsvereinbarungen, die die Vertrauensbeziehungen zu der vertrauenswürdigen Domäne bestimmen, und auf der Technologie, die zum Vertrauensaufbau eingesetzt wird. Eine vertrauenswürdige Unternehmensdomäne enthält diejenigen Komponenten, die von dem Unternehmen verwaltet werden; alle Komponenten innerhalb dieser vertrauenswürdigen Domäne vertrauen einander. Im Allgemeinen sind keine Geschäftsvereinbarungen notwendig, um Vertrauen innerhalb eines Unternehmens aufzubauen, da die eingesetzte Technologie von sich aus Vertrauen in dem Unternehmen erzeugt, z. B., indem sie SSL-Sitzungen zwischen Komponenten mit gegenseitiger Identitätsprüfung erfordert oder indem sie Komponenten so in einem einzigen, streng überwachten Datenzentrum platziert, dass physische Kontrolle und physische Nähe ein zwangsläufig vorhandenes Vertrauen zum Ausdruck bringen. Bezug nehmend auf 2B können die älteren Anwendungen und die nachgeschalteten Verarbeitungssysteme eine vertrauenswürdige Unternehmensdomäne darstellen, in der die Komponenten in einem sicheren internen Netzwerk Daten austauschen.
Vertrauenswürdige Verbunddomänen sind diejenigen, die Unternehmensgrenzen überschreiten; von einem Standpunkt aus betrachtet, kann eine vertrauenswürdige Verbunddomäne Vertrauensbeziehungen zwischen bestimmten vertrauenswürdigen Unternehmensdomänen darstellen. Vertrauenswürdige Verbunddomänen werden über vertrauenswürdige Proxys zwischen Verbundpartnern über Unternehmensgrenzen hinweg eingerichtet. Vertrauensbeziehungen schließen eine Art von Bootstrapping-Prozess zur anfänglichen Gewinnung von Einschätzungen ein, bei dem ein Anfangsvertrauen zwischen vertrauenswürdigen Proxys hergestellt wird. Ein Teil dieses Bootstrapping-Prozesses kann die Festlegung von gemeinsamen geheimen Schlüsseln und Regeln sein, die die erwarteten und/oder zulässigen Arten von Token und Kennungsumsetzungen angeben. Im Allgemeinen kann dieser Bootstrapping-Prozess bandextern erfolgen, da dieser Prozess auch die Festlegung von Geschäftsvereinbarungen beinhalten kann, die die Teilnahme eines Unternehmens an einem Verbund und die mit dieser Teilnahme verbundenen Pflichten regeln.
Es gibt mehrere mögliche Mechanismen, um Vertrauen in einem Verbundgeschäftsmodell aufzubauen. In einem Verbundmodell ist ein grundlegendes Gefühl von Vertrauen zwischen den Verbundteilnehmern aus rein geschäftlichen Gründen notwendig, um eine Ebene der Gewährleistung zu schaffen, dass die Bestätigungen (einschließlich der Token und Attributdaten), die zwischen den Teilnehmern übertragen werden, gültig sind. Wenn es keine Vertrauensbeziehung gibt, kann sich der Diensteanbieter nicht auf die vom Identitätsanbieter empfangenen Bestätigungen verlassen; der Diensteanbieter kann sie nicht zur Feststellung verwenden, wie vom Identitätsanbieter empfangene Daten auszulegen sind.
Beispielsweise möchte ein großes Unternehmen vielleicht mehrere Tausend globale Kunden miteinander verbinden und das Unternehmen könnte Lösungen nach dem Stand der Technik einsetzen. Als ein erstes Beispiel könnte das Unternehmen verlangen, dass globale Kunden ein digitales Zertifikat von einer kommerziellen Zertifizierungsstelle verwenden, um gegenseitiges Vertrauen aufzubauen. Die kommerzielle Zertifizierungsstelle ermöglicht den Servern in dem Unternehmen, Servern zu vertrauen, die sich bei jedem der globalen Kunden befinden. Als ein zweites Beispiel könnte das Unternehmen mit Hilfe von Kerberos Vertrauen über eine Drittpartei schaffen; das Unternehmen und seine globalen Kunden könnten eine dritte Partei in Form von einem vertrauenswürdigen Kerberos-Domänendienst einrichten, der Vertrauen auf der Grundlage eines gemeinsamen Geheimnisses schafft. Als ein drittes Beispiel könnte das Unternehmen ein privates Schema mit einem unternehmenseigenen Sicherheitsnachrichten-Token festlegen, dem die Server seiner globalen Kunden wechselseitig vertrauen.
Jeder dieser Ansätze ist gegebenenfalls akzeptabel, wenn das Unternehmen Vertrauensbeziehungen mit einer kleinen Anzahl von globalen Kunden verwalten muss, bei Vorhandensein von Hunderten oder Tausenden möglicher Verbundpartner ist es unter Umständen aber nicht mehr handhabbar. Es mag dem Unternehmen zwar möglich sein, seine kleineren Partner zu zwingen, ein privates Schema zu realisieren, doch ist es unwahrscheinlich, dass das Unternehmen seinen größeren Partnern viele Bedingungen diktieren kann.
Bei der vorliegenden Erfindung nutzt das Unternehmen vorzugsweise Vertrauensbeziehungen, die über vertrauenswürdige Proxys und möglicherweise vertrauenswürdige Vermittler hergestellt und unterhalten werden. Ein Vorteil der Verbundarchitektur einer Ausführungsform der vorliegenden Erfindung besteht darin, dass sie über die aktuellen Infrastrukturen eines Unternehmens und seiner möglichen Verbundpartner hinaus keine weiteren Forderungen erhebt.
Die bevorzugte Ausführungsform nimmt einem Unternehmen und seinen möglichen Verbundpartnern jedoch nicht die Vorarbeit ab, die notwendig ist, um die zur Teilnahme an dem Verbund erforderlichen geschäftlichen und die Leistungspflicht betreffenden Vereinbarungen zu treffen. Überdies können die Teilnehmer den technologischen Prozess des Bootstrapping bei einer Vertrauensbeziehung nicht ignorieren. Vorzugsweise ermöglicht die vorliegende Erfindung, dass dieser Bootstrapping-Prozess flexibel ist, beispielsweise kann ein erster Verbundpartner ein Kerberos-Ticket mit bestimmten Daten ausgeben, während ein zweiter Verbundpartner eine SAML-Identitätsbestätigung mit bestimmten Daten ausgeben kann.
Bei der vorliegenden Erfindung werden die Vertrauensbeziehungen vorzugsweise von den vertrauenswürdigen Proxys verwaltet, die einen Sicherheitstoken-Dienst enthalten (oder mit diesem interaktiv kommunizieren) können, der ein Token, das auf der Grundlage der vorab hergestellten Beziehung zwischen zwei vertrauenswürdigen Proxys von einem Identitätsanbieter empfangen wurde, auf Gültigkeit prüft und umsetzt. In Situationen, in denen es einem Verbundunternehmen nicht möglich ist, Vertrauensbeziehungen zu einem anderen Verbundunternehmen herzustellen (und die Umsetzung von Token vorzunehmen), kann ein vertrauenswürdiger Vermittler aufgerufen werden; das Verbundunternehmen müsste dann jedoch eine Beziehung zu einem vertrauenswürdigen Vermittler herstellen.
Nun Bezug nehmend auf 2D zeigt ein Blockschaubild mehrere beispielhafte Vertrauensbeziehungen zwischen Verbunddomänen unter Verwendung von vertrauenswürdigen Proxys und einem vertrauenswürdigen Vermittler gemäß einer Ausführungsform der vorliegenden Erfindung. Zwar wurde in 2C der vertrauenswürdige Vermittler eingeführt, doch veranschaulicht 2D die Bedeutung von transitiven Vertrauensbeziehungen in der Verbundarchitektur einer Ausführungsform der vorliegenden Erfindung.
Die Verbunddomänen 271 bis 273 enthalten die jeweiligen vertrauenswürdigen Proxys 274 bis 276. Der vertrauenswürdige Proxy 274 unterhält eine direkte Vertrauensbeziehung 277 zu dem vertrauenswürdigen Proxy 275. Der vertrauenswürdige Vermittler 280 unterhält eine direkte Vertrauensbeziehung 278 zu dem vertrauenswürdigen Proxy 275, und der vertrauenswürdige Vermittler 280 unterhält eine direkte Vertrauensbeziehung 279 zu dem vertrauenswürdigen Proxy 276. Der vertrauenswürdige Vermittler 280 dient dazu, im Namen eines Verbundteilnehmers auf der Grundlage des transitiven Vertrauens eine Vertrauensbeziehung zu anderen Verbundpartnern herzustellen. Die Grundsätze des transitiven Vertrauens ermöglichen dem vertrauenswürdigen Proxy 275 und dem vertrauenswürdigen Proxy 276, eine vom vertrauenswürdigen Vermittler 280 vermittelte Vertrauensbeziehung 281 zu unterhalten. Weder der vertrauenswürdige Proxy 275 noch der vertrauenswürdige Proxy 276 müssen wissen, wie die Bestätigungen des jeweils anderen vertrauenswürdigen Proxy umzusetzen oder auf Gültigkeit zu prüfen sind; der vertrauenswürdige Vermittler kann aufgerufen werden, um eine Bestätigung in eine gültige, vertrauenswürdige und für den anderen vertrauenswürdigen Proxy verständliche Bestätigung umzusetzen.
Geschäftsvereinbarungen, die vertragliche Verpflichtungen sowie Haftungsfragen in Bezug auf die Vertrauensbeziehungen zwischen Verbundunternehmen festlegen, können durch die Verwendung von ebXML-Standards (ebXML steht für Electronic Business using XML) in XML ausgedrückt werden. Beispielsweise könnte eine direkte Vertrauensbeziehung in einem ebXML-Dokument dargestellt werden; jede Verbunddomäne, die an einer direkten Vertrauensbeziehung beteiligt ist, würde eine Ausfertigung eines Vertrages haben, der in Form eines ebXML-Dokuments ausgedrückt ist. Betriebseigenschaften von verschiedenen Einheiten in einem Verbund können in ebXML-Choreographien angegeben und in ebXML-Registrierdatenbanken veröffentlicht werden; jedes Unternehmen, das an einem bestimmten Verbund teilnehmen möchte, z. B., um einen vertrauenswürdigen Proxy oder einen vertrauenswürdigen Vermittler zu betreiben, müsste den veröffentlichten Anforderungen entsprechen, die von dem jeweiligen Verbund für alle vertrauenswürdigen Proxys oder vertrauenswürdigen Vermittler in dem Verbund festgelegt wurden. Ein Sicherheitstoken-Dienst könnte diese ebXML-Dokumente hinsichtlich betrieblicher Einzelheiten über die Art und Weise auswerten, in der Token von anderen Domänen umgesetzt werden müssen. Es sei jedoch angemerkt, dass die vorliegende Erfindung auch andere Standards und Mechanismen verwenden könnte, um die Einzelheiten über die Art und Weise festzulegen, in der die Vertrauensbeziehungen in einem Verbund hergestellt werden.
Die Verarbeitung von Bestätigungen innerhalb einer Verbundarchitektur
Wie zuvor erwähnt wurde, wird die Erfahrung eines Benutzers in einem Verbund zum Teil von den Bestätigungen über oder für den Benutzer bestimmt, die domänenübergreifend übertragen werden. Bestätigungen geben Auskunft über den Status der Identitätsprüfung des Benutzers und stellen Attribut- und sonstige Daten bereit. Die Verwendung von Identitätsbestätigungen kann es für einen Benutzer überflüssig machen, seine Identität auf jeder Website, die er besucht, erneut nachzuweisen. In einer Verbundumgebung gibt es zwei Modelle, eine Bestätigung von einer ausgebenden Domäne an eine sich auf die Vertrauenswürdigkeit verlassende Domäne zu übertragen: Sendemodelle (push models) und Empfangsmodelle (pull models). Bei einem Sendemodell wandern die Bestätigungen des Benutzers zusammen mit seiner Anforderung zu der sich auf die Vertrauenswürdigkeit verlassende Domäne. Bei einem Empfangsmodell wird die Anforderung des Benutzers in einer sich auf die Vertrauenswürdigkeit verlassenden Domäne ohne einige notwendige Daten empfangen, und die sich auf die Vertrauenswürdigkeit verlassende Domäne fordert dann die entsprechenden oder benötigten Bestätigungen von der ausgebenden Domäne an.
Unter Berücksichtigung dieser Modelle zur Verwendung von Bestätigungen in einer Verbundumgebung wendet sich die Beschreibung nun einer Reihe von Figuren zu, die mehrere Prozesse zur Erzeugung und Verwendung von Bestätigungen in der Verbundumgebung der bevorzugten Ausführungsform aufzeigen. 3A zeigt einen verallgemeinerten Prozess, der in einer ausgebenden Domäne oder an einer ausgebenden Partei zur Erzeugung einer Bestätigung in einer Verbundumgebung stattfindet, während 3B einen verallgemeinerten Prozess zeigt, der in einer sich auf die Vertrauenswürdigkeit verlassenden Domäne oder an einer sich auf die Vertrauenswürdigkeit verlassenden Partei stattfindet und dazu dient, eine Bestätigung zu "zerlegen" ("tear down"), d. h., eine Bestätigung auf ihre wesentlichen Daten zu reduzieren, indem man ihr diese Daten entnimmt und sie auswertet. 3C und 3D zeigen ausführlichere Prozesse für den in 3A gezeigten verallgemeinerten Prozess, wobei zwei Varianten eines Sendemodells dargestellt werden, bei dem eine Bestätigung in einer ausgebenden Domäne erzeugt und anschließend zusammen mit der Anforderung eines Benutzers an die sich auf die Vertrauenswürdigkeit verlassende Domäne übertragen wird. 3E zeigt ein Empfangsmodell, bei dem eine sich auf die Vertrauenswürdigkeit verlassende Domäne erforderliche Bestätigungen für einen Benutzer von einer ausgebenden Domäne anfordert, während sie versucht, eine Ressourcenanforderung zu erfüllen, welche die sich auf die Vertrauenswürdigkeit verlassende Domäne von dem anfordernden Benutzer empfangen hat.
Nun Bezug nehmend auf 3A zeigt ein Flussdiagramm einen verallgemeinerten Prozess in einer ausgebenden Domäne zur Erzeugung einer Bestätigung in einer Verbundumgebung. Der Prozess beginnt, wenn der Kontaktserver der ausgebenden Domäne um eine Bestätigung ersucht wird (Schritt 302). Der Kontaktserver kann eine Anforderung für eine bestimmte Bestätigung für einen bestimmten Benutzer von einer sich auf die Vertrauenswürdigkeit verlassenden Domäne empfangen oder er kann eine abgehende Anforderung an eine bekannte, sich auf die Vertrauenswürdigkeit verlassende Domäne, die eine Bestätigung braucht, abfangen; diese Szenarien werden nachstehend mit Bezug auf 3C beziehungsweise 3D ausführlicher beschrieben. Als Reaktion darauf, dass er um eine Bestätigung ersucht wird, fordert der Kontaktserver der ausgebenden Domäne die Bestätigung vom vertrauenswürdigen Proxy der ausgebenden Domäne an (Schritt 304), der die Bestätigung erzeugt (Schritt 306) und vertrauenswürdige Daten wie zum Beispiel eine Verschlüsselung/Signatur der Bestätigung/des Token hinzufügt; der vertrauenswürdige Proxy der ausgebenden Domäne kann bei Bedarf Hilfe von einem vertrauenswürdigen Vermittler anfordern, um die benötigte Bestätigung zu erzeugen. Nachdem er die Bestätigung erzeugt hat, schickt der vertrauenswürdige Proxy der ausgebenden Domäne die Bestätigung an den Kontaktserver der ausgebenden Domäne zurück (Schritt 308), der die Bestätigung daraufhin in geeigneter Weise in den Ausgangsdatenstrom einfügt (Schritt 310), zum Beispiel, indem er die Bestätigung in eine abgehende HTTP- oder SOAP-Nachricht einfügt, wodurch der Prozess beendet wird.
3A zeigt einen Prozess zur Erzeugung einer Bestätigung in einer ausgebenden Domäne ohne Verwendung einer "lokalen Geldbörse". Die vorliegende Erfindung ermöglicht vorzugsweise jedoch die Einbindung einer Funktion in Form von einer lokalen Geldbörse. Im Allgemeinen handelt es sich bei einer lokalen Geldbörse um clientseitigen Code, der als sicherer Datenspeicher für Attributdaten des Benutzers oder für andere Daten dienen kann, um Transaktionen zu vereinfachen; der clientseitige Code kann auch an den Sende- und/oder Empfangsmodellen für die Übertragung von Bestätigungen beteiligt sein. Wenn die lokale Geldbörse aktiv an dem Protokoll teilnimmt, führt sie einen Teil der Funktionen der vom Kontaktserver bereitgestellten Funktionalität in Form des Erzeugens und Einfügens von Bestätigungen in den Protokollfluss aus. Bei Verwendung einer lokalen Geldbörse darf die lokale Geldbörse die vertrauensbasierten Interaktionen, die zwischen einem Kontaktserver und dem vertrauenswürdigen Proxy stattfinden, nicht durchführen. In Fällen, in denen zusätzliche Vertrauensbeziehungen erforderlich sind, muss der Kontaktserver aufgerufen werden.
Nun Bezug nehmend auf 3B zeigt ein Flussdiagramm einen verallgemeinerten Prozess in einer sich auf die Vertrauenswürdigkeit verlassenden Domäne, mittels dessen eine Bestätigung zerlegt wird. Der Prozess beginnt, wenn der Kontaktserver einer sich auf die Vertrauenswürdigkeit verlassenden Domäne eine Nachricht mit einer zugehörigen Bestätigung empfängt (Schritt 322), woraufhin er die Bestätigung entnimmt und sie an den vertrauenswürdigen Proxy der sich auf die Vertrauenswürdigkeit verlassenden Domäne weiterleitet (Schritt 324). Der vertrauenswürdige Proxy der sich auf die Vertrauenswürdigkeit verlassenden Domäne entnimmt der Bestätigung Daten, einschließlich des von der ausgebenden Domäne empfangenen Token (Schritt 326); der vertrauenswürdige Proxy der sich auf die Vertrauenswürdigkeit verlassenden Domäne ruft den Sicherheitstoken-Dienst auf, um dieses Token einschließlich der Daten in dem Token und der vertrauenswürdigen Daten auf dem Token wie zum Beispiel Verschlüsselung und Signaturen auf Gültigkeit zu prüfen, und anschließend schickt er gegebenenfalls ein lokal gültiges Token für den Benutzer zurück (Schritt 328).
Als Teil des Schrittes 326 ermittelt der vertrauenswürdige Proxy die Quelle, d. h. die ausgebende Partei, der Bestätigung. Wenn der vertrauenswürdige Proxy eine von dieser ausgebenden Domäne empfangene vertrauenswürdige Bestätigung verstehen kann, führt er intern den Schritt 328 durch. Wenn der vertrauenswürdige Proxy die von dieser ausgebenden Domäne empfangenen Bestätigungen nicht verstehen beziehungsweise diesen nicht vertrauen kann, kann er Hilfe von einem vertrauenswürdigen Vermittler anfordern. Wenn die Bestätigung nicht für gültig erklärt werden könnte, würde eine entsprechende Fehlermeldung als Antwort erzeugt werden.
Unter der Annahme, dass die Bestätigung für gültig erklärt wird, erstellt der vertrauenswürdige Proxy der sich auf die Vertrauenswürdigkeit verlassenden Domäne die lokalen Daten, die der Benutzer benötigt (Schritt 330). Die lokalen Daten können beispielsweise Anmeldedaten enthalten, die von einer älteren nachgeschalteten Anwendung benötigt werden. Der vertrauenswürdige Proxy der sich auf die Vertrauenswürdigkeit verlassenden Domäne schickt die erforderlichen Daten an den Kontaktserver der sich auf die Vertrauenswürdigkeit verlassenden Domäne zurück (Schritt 332), der eine lokale Sitzung für den Benutzer aufbaut.
Nachdem der Kontaktserver eine Sitzung für den Benutzer aufgebaut hat, erscheint der Benutzer als ein Benutzer, dessen Identität bestätigt wurde. Der Kontaktserver kann diese Sitzungsdaten verwenden, um Transaktionen, die der Benutzer mit der Domäne durchführt, weiterhin zu steuern, bis ein Abmelde- oder Zeitüberschreitungsereignis eingeleitet wird. Unter der Voraussetzung, dass der Kontaktserver eine bestätigte Identität für den Benutzer hat, kann er bei Bedarf auf der Grundlage der Identität dieses bestimmten Benutzers und auf der Grundlage von Genehmigungsverfahren, die mit diesem bestimmten Benutzer verbunden sind, eine Genehmigung für diese Anforderung erhalten. Der Kontaktserver leitet die Anforderung des Benutzers mit allen zugehörigen Daten an die nachgeschaltete Anwendung oder den nachgeschalteten Dienst weiter, die beziehungsweise der die Anforderung gestellt hat (Schritt 334), wodurch der Prozess beendet wird.
Es sei angemerkt, dass die Datenelemente, die zwischen dem Kontaktserver und dem vertrauenswürdigen Proxy übertragen werden, und das Format dieser Datenelemente unterschiedlich sein können. Statt der Nachricht eine Bestätigung zu entnehmen und nur die Bestätigung an den vertrauenswürdigen Proxy weiterzuleiten, kann der Kontaktserver die ganze Nachricht an den vertrauenswürdigen Proxy weiterleiten. Die Verarbeitung an dem vertrauenswürdigen Proxy kann beispielsweise Schritte wie die Prüfung der in einer SOAP-Nachricht enthaltenen Signatur auf Gültigkeit beinhalten, was den ganzen SOAP-Umschlag erforderlich machen würde.
Nun Bezug nehmend auf 3C zeigt ein Flussdiagramm einen bestimmten Prozess, der dazu dient, eine Bestätigung von einer ausgebenden Domäne als Reaktion auf eine in der ausgebenden Domäne stattfindende Benutzeraktion an eine sich auf die Vertrauenswürdigkeit verlassende Domäne zu senden. Der Prozess beginnt, wenn ein Benutzer von einer Webseite oder einer ähnlichen Ressource in der ausgebenden Domäne auf eine Verknüpfung zu der sich auf die Vertrauenswürdigkeit verlassenden Domäne zugreift (Schritt 342), wodurch eine bestimmte Form einer Verarbeitung vom Typ CGI (Common Gateway Interface) aufgerufen wird, um eine bestimmte Bestätigung zu erstellen. Die Fähigkeit der ausgebenden Domäne, den seitens der sich auf die Vertrauenswürdigkeit verlassenden Domäne bestehenden Bedarf für eine Bestätigung zu erkennen, setzt eine enge Einbindung in ein vorhandenes älteres System voraus, auf dem die Verbundinfrastruktur der vorliegenden Erfindung vorzugsweise realisiert wird. Sie setzt auch eine enge Verbindung zwischen der ausgebenden Partei und der sich auf die Vertrauenswürdigkeit verlassenden Partei voraus, so dass die ausgebende Partei keinen vertrauenswürdigen Proxy aufrufen muss, um die erforderliche Bestätigung zu erstellen; diese enge Verbindung kann zwischen bestimmten Arten von Verbundeinheiten, die über gut etablierte Vertrauensbeziehungen verfügen, angemessen sein.
Eine nachgeschaltete Verarbeitungsfunktion in der ausgebenden Domäne wird aufgerufen, um die benötigte Bestätigung zu erstellen (Schritt 344), wobei gegebenenfalls auch Funktionen am lokalen vertrauenswürdigen Proxy aufgerufen werden müssen. Die Anforderung des Benutzers an die sich auf die Vertrauenswürdigkeit verlassende Domäne einschließlich der benötigten Bestätigung wird dann erstellt (Schritt 346), und die ausgebende Domäne überträgt die Bestätigung zusammen mit der Anforderung des Benutzers an die sich auf die Vertrauenswürdigkeit verlassende Domäne (Schritt 348), wodurch der Prozess beendet wird. Wenn die sich auf die Vertrauenswürdigkeit verlassende Domäne die Anforderung und ihre zugehörige Bestätigung empfängt, prüft die sich auf die Vertrauenswürdigkeit verlassende Domäne die Bestätigung in der in 3B gezeigten Weise.
Nun Bezug nehmend auf 3D zeigt ein Flussdiagramm einen bestimmten Prozess, der dazu dient, eine Bestätigung von einer ausgebenden Domäne an eine sich auf die Vertrauenswürdigkeit verlassende Domäne zu senden, und zwar als Reaktion darauf, dass die ausgebende Domäne aktiv eine abgehende Anforderung an die sich auf die Vertrauenswürdigkeit verlassende Domäne abfängt. Der Prozess beginnt, wenn ein Benutzer eine geschützte Ressource in der sich auf die Vertrauenswürdigkeit verlassenden Domäne anfordert (Schritt 352). Der Kontaktserver fängt die abgehende Anforderung ab (Schritt 354), beispielsweise, indem er abgehende Nachrichten nach vorher festgelegten Adressen von im Internet liegenden Ressourcen (Uniform Resource Identifiers (URIs)), bestimmten Arten von Nachrichten, einer bestimmten Art von Nachrichteninhalt oder auf andere Weise filtert. Der Kontaktserver der ausgebenden Domäne fordert dann die Erzeugung einer entsprechenden Bestätigung vom vertrauenswürdigen Proxy der ausgebenden Domäne an (Schritt 356), der die Bestätigung bei Bedarf mit Hilfe eines vertrauenswürdigen Vermittlers erzeugt (Schritt 358). Die ausgebende Domäne überträgt dann die Anforderung des Benutzers zusammen mit der erzeugten Bestätigung an die sich auf die Vertrauenswürdigkeit verlassende Partei (Schritt 360), wodurch der Prozess beendet wird. Wenn die sich auf die Vertrauenswürdigkeit verlassende Domäne die Anforderung und ihre zugehörige Bestätigung empfängt, prüft die sich auf die Vertrauenswürdigkeit verlassende Domäne die Bestätigung in der in 3B gezeigten Weise.
Nun Bezug nehmend auf 3E zeigt ein Flussdiagramm ein Empfangsmodell, bei dem eine sich auf die Vertrauenswürdigkeit verlassende Domäne erforderliche Bestätigungen für einen Benutzer von einer ausgebenden Domäne anfordert, während sie versucht, eine Anforderung für eine Ressource zu erfüllen, welche die sich auf die Vertrauenswürdigkeit verlassende Domäne von dem anfordernden Benutzer empfangen hat. Der Prozess beginnt, wenn die sich auf die Vertrauenswürdigkeit verlassende Domäne eine Anforderung von einem Benutzer für eine geschützte Ressource empfangt (Schritt 372). Im Gegensatz zu den in 3C oder 3D gezeigten Beispielen beschreibt das in 3E gezeigte Beispiel die Verarbeitungsoperationen in Verbindung mit der Anforderung eines Benutzers, welche in einer sich auf die Vertrauenswürdigkeit verlassenden Domäne empfangen wird, und zwar bei Nichtvorhandensein von erforderlichen Bestätigungen über einen Benutzer. In diesem Fall hatte die ausgebende Domäne nicht die Möglichkeit, die Anforderung des Benutzers abzufangen oder anderweitig zu verarbeiten, um die erforderlichen Bestätigungen in die Anforderung des Benutzers einzufügen. Beispielsweise hat der Benutzer vielleicht eine Verweisadresse (Uniform Resource Locator (URL)) eines Internet-Dokuments eingegeben oder einen mit einem Lesezeichen versehenen Verweis auf eine Ressource so verwendet, dass die abgehende Anforderung nicht vom Kontaktserver einer ausgebenden Domäne abgefangen wurde. Daher fordert die sich auf die Vertrauenswürdigkeit verlassende Domäne die Bestätigung von einer ausgebenden Domäne an.
Die sich auf die Vertrauenswürdigkeit verlassende Domäne ermittelt dann die Heimdomäne des Benutzers (Schritt 374), d. h. die relevante ausgebende Domäne. In einer auf HTTP beruhenden Ausführungsart hat der Benutzer gegebenenfalls vorab eine Beziehung zu der sich auf die Vertrauenswürdigkeit verlassenden Domäne hergestellt, in deren Folge die sich auf die Vertrauenswürdigkeit verlassende Domäne ein bleibendes Cookie (eine kleine Textdatei) auf der Client-Einheit des Benutzers hinterlegt hat. Das bleibende Cookie würde die Kennung der Heimdomäne oder des Identitätsanbieters des Benutzers enthalten, d. h. die entsprechende ausgebende Domäne. In einer auf SOAP beruhenden Ausführungsart, bei der der Benutzer einen Client für Webdienste auf eine bestimmte Art und Weise betreibt, hätte der Webdienst in der sich auf die Vertrauenswürdigkeit verlassenden Domäne die Diensteanforderungen über WSDL (Web Services Description Language), die Token-Anforderungen enthalten, angezeigt. Dann müsste der Client für Webdienste/die SOAP-Ausführung des Benutzers die Art des erforderlichen Token angeben. Wenn diese Anforderung nicht erfüllt würde, würde der Webdienst genau genommen eine Fehlermeldung zurücksenden. In manchen Fällen kann er einen Fehlercode zurücksenden, wodurch der Client für Webdienste des Benutzers zur Eingabe von Daten zur Identitätsprüfung aufgefordert werden könnte, so dass die Anforderung mit dem richtigen Token wiederholt werden könnte.
Der Kontaktserver der sich auf die Vertrauenswürdigkeit verlassenden Domäne leitet eine Anforderung für eine Bestätigung ein, die an den vertrauenswürdigen Proxy der sich auf die Vertrauenswürdigkeit verlassenden Domäne gerichtet ist (Schritt 376), welcher eine Bestätigung für den Benutzer von dem vertrauenswürdigen Proxy der ausgebenden Domäne anfordert (Schritt 378). Wenn die Ausführungsform eine auf HTTP beruhende Datenübertragung realisiert, kann eine Anforderung für eine Bestätigung von dem vertrauenswürdigen Proxy der sich auf die Vertrauenswürdigkeit verlassenden Domäne an den vertrauenswürdigen Proxy der ausgebenden Domäne von dem Kontaktserver der sich auf die Vertrauenswürdigkeit verlassenden Domäne mittels Umleitung über die Browser-Anwendung des Benutzers an den Kontaktserver in der ausgebenden Domäne übertragen werden, welcher die Anforderung für die Bestätigung an den vertrauenswürdigen Proxy der ausgebenden Domäne weiterleitet.
Wenn die Ausführungsform von einer auf SOAP beruhenden Ausführung Gebrauch macht, kann die sich auf die Vertrauenswürdigkeit verlassende Partei einen Fehlercode an den Webdienste-Client des Benutzers zurückschicken. Dieser Fehlercode ermöglicht es, den Benutzer zur Eingabe von Daten zur Identitätsprüfung durch seinen Webdienste-Client aufzufordern. Der Client für Webdienste würde dann das angeforderte Token erzeugen. Der Webdienste-Client des Benutzers könnte direkt einen vertrauenswürdigen Proxy aufrufen, vorausgesetzt, dass der vertrauenswürdige Proxy der sich auf die Vertrauenswürdigkeit verlassenden Domäne in einer UDDI-Registrierdatenbank (UDDI steht für Universal Description, Discovery, and Integration) verzeichnet ist, wodurch der Webdienste-Client des Benutzers den vertrauenswürdigen Proxy finden könnte. Im Allgemeinen gilt dieses Szenario nur für einen internen Benutzer, bei dem der vertrauenswürdige Proxy in einer privaten UDDI innerhalb des Unternehmens angezeigt wird, da es unwahrscheinlich ist, dass ein vertrauenswürdiger Proxy in einer öffentlichen UDDI im Internet angezeigt wird oder außerhalb eines Verbunds allgemein auf ihn zugegriffen werden kann.
Der vertrauenswürdige Proxy der ausgebenden Domäne erzeugt (Schritt 380) die angeforderte Bestätigung und sendet sie anschließend in einer Art und Weise zurück, die die Art und Weise widerspiegelt, in der die Anforderung für die Bestätigung empfangen wurde. Nachdem der vertrauenswürdige Proxy der sich auf die Vertrauenswürdigkeit verlassenden Domäne die angeforderte Bestätigung empfangen hat (Schritt 384), entnimmt er der Bestätigung Daten (Schritt 386) und versucht, die Bestätigung auszuwerten und/oder auf Gültigkeit zu prüfen (Schritt 388); der vertrauenswürdige Proxy kann zur Umsetzung der Bestätigung bei Bedarf Hilfe von einem vertrauenswürdigen Vermittler anfordern. Wenn die Bestätigung nicht für gültig erklärt werden könnte, würde eine entsprechende Fehlermeldung als Antwort erzeugt werden. Unter der Annahme, dass die Bestätigung für gültig erklärt wird, erstellt der vertrauenswürdige Proxy der sich auf die Vertrauenswürdigkeit verlassenden Domäne die lokalen Daten in einem geeigneten Format, das zur Verwendung durch die nachgeschalteten Dienste benötigt wird, die versuchen, die Anforderung des Benutzers für die geschützte Ressource zu erfüllen (Schritt 390). Die lokalen Daten können beispielsweise Anmeldedaten enthalten, die von einer älteren nachgeschalteten Anwendung benötigt werden. Der vertrauenswürdige Proxy der sich auf die Vertrauenswürdigkeit verlassenden Domäne schickt die erforderlichen Daten an den Kontaktserver der sich auf die Vertrauenswürdigkeit verlassenden Domäne zurück (Schritt 392), der dann eine lokale Sitzung für den Benutzer aufbaut und die Anforderung des Benutzers mit allen zugehörigen Daten an die nachgeschaltete Anwendung oder den nachgeschalteten Dienst weiterleitet, die beziehungsweise der die Anforderung gestellt hat (Schritt 394), wodurch der Prozess beendet wird.
Einmalanmeldung innerhalb einer Verbundarchitektur
Die Beschreibung der 2A bis 2D konzentriert sich auf die Betriebseigenschaften von Einheiten in einer Datenverarbeitungs-Verbundumgebung gemäß einer Ausführungsform der vorliegenden Erfindung, wohingegen sich die Beschreibung der 3A bis 3E auf einige der Prozesse konzentriert, die zwischen diesen Einheiten stattfinden. Im Gegensatz zu diesen Beschreibungen wird Bezug auf 4 hinsichtlich einer Beschreibung genommen, in deren Mittelpunkt die Zielsetzung der Durchführung von Transaktionen für einen Benutzer steht, während dem Benutzer die Möglichkeit gegeben wird, die Erfahrung einer Einmalanmeldung zu machen.
Anders ausgedrückt, in der nachstehenden Beschreibung werden die Einheiten und die Prozesse erörtert, die bereits vorstehend erläutert wurden, doch soll in der folgenden Beschreibung schwerpunktmäßig eher ein Überblick über die Art und Weise gegeben werden, in der ein Benutzer während seiner Sitzung die Erfahrung einer Einmalanmeldung machen kann. Eine Sitzung kann als die Reihe von Transaktionen definiert werden, die zwischen dem Zeitpunkt der ersten Identitätsprüfung des Benutzers (wobei dieser Zeitpunkt eingeschlossen ist), d. h. der Anmeldung, und seiner Abmeldung liegen. Während einer Sitzung werden die Aktionen eines Benutzers zum Teil von den Zugriffsrechten bestimmt, die ihm für diese Sitzung gewährt wurden. In einem Verbund geht ein Benutzer davon aus, die Erfahrung einer Einmalanmeldung machen zu können, bei der er eine einzige Identitätsprüfungsoperation durchführt, und diese Identitätsprüfungsoperation ist für die Dauer seiner Sitzung ausreichend, ungeachtet der während seiner Sitzung besuchten Verbundpartner.
Während seiner Sitzung kann der Benutzer viele Verbunddomänen besuchen, um die Webdienste in Anspruch zu nehmen, die diese Domänen bieten. Domänen können Beschreibungen von Diensten, die sie bereitstellen, unter Verwendung von Standardspezifikationen wie UDDI und WSDL veröffentlichen, die beide XML als Standarddatenformat verwenden. Der Benutzer findet die verfügbaren Dienste und Diensteanbieter über Anwendungen, die diese Standardspezifikationen ebenfalls einhalten. SOAP stellt ein Paradigma zur Übertragung von Anforderungen und Antworten bereit, die in XML ausgedrückt werden. Einheiten in einer Verbundumgebung können unter anderem diese Standards einsetzen.
Um eine Einmalanmeldung zu vereinfachen, unterstützt der Webdienst, der auch die Verbundumgebung unterstützt, die Verwendung einer Identitätsbestätigung oder eines Sicherheits-Token, die beziehungsweise das von einer dritten Partei erzeugt wurde, um den Identitätsnachweis eines Benutzers zu erbringen. Diese Bestätigung enthält einen Nachweis, dass der Benutzer seine Identität gegenüber der ausgebenden Partei erfolgreich bestätigen konnte, und sie enthält auch eine Kennung dieses Benutzers. Folglich kann ein Benutzer einem Verbundpartner herkömmliche Anmeldedaten übergeben, z. B. einen Benutzernamen und ein Passwort, und anschließend kann er einem anderen Verbundpartner eine SAML-Identitätsbestätigung vorlegen, die von der die Identitätsfeststellung durchführenden Partei/ausgebenden Partei erzeugt wurde.
Die Identitätsprüfung in einer Webdienste-Umgebung ist der Vorgang, bei dem die vorgegebene Identität der Webdienste-Anforderung auf Gültigkeit geprüft wird, so dass das Unternehmen den Zugriff auf berechtigte Clients beschränken kann. Die Identität eines Benutzers, der einen Webdienst anfordert oder aufruft, würde fast immer geprüft werden, so dass sich die Notwendigkeit der Identitätsprüfung in der Verbundumgebung der vorliegenden Erfindung gemäß einer Ausführungsform nicht von den derzeitigen Erfordernissen bei Webdiensten hinsichtlich der Identitätsprüfung von Benutzern unterscheidet. In der Verbundumgebung haben auch Webdienste oder andere Anwendungen die Möglichkeit, Webdienste anzufordern, und die Identität dieser Webdienste würde ebenfalls geprüft werden.
Die Verbundarchitektur einer Ausführungsform der vorliegenden Erfindung hat keine Auswirkung auf die Identitätsprüfung von Benutzern, die nicht an einer Verbundsitzung teilnehmen. Ein vorhandener Benutzer beispielsweise, der seine Identität mit einem formularbasierten Identitätsprüfungsmechanismus über HTTP/S nachweist, um auf Ressourcen in einer bestimmten Domäne zuzugreifen, die nicht zum Verbund gehören, bleibt von der Einführung von Unterstützungsdiensten in der Domäne für die Verbundumgebung unberührt. Die Identitätsprüfung wird zum Teil von einem Kontaktserver durchgeführt, der wiederum eine gesonderte Komponente in Form des vertrauenswürdigen Proxy aufrufen kann. Durch die Verwendung eines Kontaktservers wird die Auswirkung auf die Infrastruktur einer vorhandenen Domäne auf ein Mindestmaß reduziert. Der Kontaktserver kann zum Beispiel so konfiguriert werden, dass er alle Anforderungen, die nicht aus dem Verbund stammen und von den nachgeschalteten oder älteren Anwendungen und Systemen in der Domäne verarbeitet werden sollen, durchstellt.
Es ist dem Kontaktserver freigestellt, ein auf HTTP beruhendes Identitätsprüfungsverfahren wie zum Beispiel eine grundlegende Identitätsprüfung, eine formularbasierte Identitätsprüfung oder ein anderes Identitätsprüfungsverfahren aufzurufen. Der Kontaktserver unterstützt auch eine vertrauenswürdige Verbunddomäne, indem er eine Bestätigung anerkennt, die vom Benutzer als Identitätsnachweis übergeben wurde, wie zum Beispiel eine SAML-Identitätsbestätigung, wobei die Bestätigung zwischen vertrauenswürdigen Domänen im Unternehmen weitergereicht wurde. Der Kontaktserver kann den vertrauenswürdigen Proxy aufrufen, der wiederum seinen Sicherheitstoken-Dienst aufrufen kann, um Anmeldedaten/Sicherheits-Token auf Gültigkeit zu prüfen.
Die Identitätsprüfung von Webdiensten oder anderen Anwendungen umfasst denselben Prozess wie die Identitätsprüfung von Benutzern. Bei Anforderungen von Webdiensten wird ein Sicherheitstoken mitgeführt, das eine Identitätsbestätigung enthält, und dieses Sicherheits-Token würde von dem vertrauenswürdigen Proxy/dem Sicherheitstoken-Dienst in der gleichen Weise auf Gültigkeit geprüft werden wie ein von einem Benutzer übergebenes Token. Bei einer Anforderung von einem Webdienst sollte immer dieses Token dabei sein, da der Webdienst erkannt hätte, welche Identitätsbestätigungen/Sicherheits-Token von dem angeforderten Dienst benötigt worden wären, der im UDDI angegeben war.
Nun Bezug nehmend auf 4 zeigt ein Blockschaubild eine Verbundumgebung, die Einmalanmeldeoperationen im Verbund unterstützt. Der Benutzer 400 möchte über eine Client-Einheit und eine entsprechende Client-Anwendung wie zum Beispiel ein Browser auf einen Webdienst zugreifen, der von dem Unternehmen/der Domäne 410 bereitgestellt wird, die Datenverarbeitungssysteme unterstützt, welche in einer Verbundumgebung die Funktion einer Verbunddomäne übernehmen. Die Domäne 410 unterstützt den Kontaktserver 412 und den vertrauenswürdigen Proxy 414; ebenso unterstützt die Domäne 420 den Kontaktserver 422 und den vertrauenswürdigen Proxy 424, während die Domäne 430 den Kontaktserver 432 und den vertrauenswürdigen Proxy 434 unterstützt. Die vertrauenswürdigen Proxys verlassen sich auf den vertrauenswürdigen Vermittler 450, wenn sie Hilfe brauchen, wie vorstehend beschrieben wurde. Weitere Domänen und vertrauenswürdige Proxys können an der Verbundumgebung teilnehmen. 4 beschreibt eine Einmalanmeldeoperation im Verbund zwischen der Domäne 410 und der Domäne 420; eine ähnliche Operation kann zwischen der Domäne 410 und der Domäne 430 stattfinden.
Der Benutzer führt eine Identitätsprüfungsoperation in Bezug auf die Domäne 410 aus; diese Identitätsprüfungsoperation wird von einem Kontaktserver 412 abgewickelt. Die Identitätsprüfungsoperation wird gestartet, wenn der Benutzer den Zugriff auf eine Ressource anfordert, die einen Identitätsnachweis erfordert, beispielsweise zum Zweck der Zugriffssteuerung oder für Personalisierungszwecke. Der Kontaktserver 412 kann einen älteren Identitätsprüfungsdienst oder aber einen vertrauenswürdigen Proxy 414 aufrufen, um die Anmeldedaten des Benutzers auf Gültigkeit zu prüfen. Die Domäne 410 wird für die Dauer der Verbundsitzung des Benutzers dessen Identitätsanbieter oder seine Heimdomäne.
Zu einem späteren Zeitpunkt leitet der Benutzer eine Transaktion an einem Verbundpartner wie zum Beispiel am Unternehmen 420 ein, das auch eine Verbunddomäne unterstützt, wodurch eine Einmalanmeldeoperation im Verbund gestartet wird. Beispielsweise kann ein Benutzer eine neue Transaktion in der Domäne 420 einleiten, oder die ursprüngliche Transaktion des Benutzers kann sich in eine oder mehrere zusätzliche Transaktionen in anderen Domänen gliedern. Als ein weiteres Beispiel kann der Benutzer eine Einmalanmeldeoperation im Verbund bei einer Ressource in der Domäne 420 über den Kontaktserver 412 aufrufen, z. B., indem er eine spezielle Verbindung auf einer Webseite auswählt, die sich in der Domäne 410 befindet, oder indem er eine Portalseite anfordert, die sich in der Domäne 410 befindet, die aber Ressourcen anzeigt, die sich in der Domäne 420 befinden. Der Kontaktserver 412 sendet eine Anforderung an den vertrauenswürdigen Proxy 414, um ein im Verbund gültiges Einmalanmelde-Token für den Benutzer zu erzeugen, das so formatiert wird, dass es für die Domäne 420 verständlich ist beziehungsweise die Domäne 420 diesem Token vertrauen kann. Der vertrauenswürdige Proxy 414 schickt dieses Token an den Kontaktserver 412 zurück, der es an den Kontaktserver 422 in der Domäne sendet. Die Domäne 410 dient als ausgebende Partei für den Benutzer in der Domäne 420, welche die Funktion einer sich auf die Vertrauenswürdigkeit verlassenden Partei hat. Das Token des Benutzers würde zusammen mit der Anforderung des Benutzers an die Domäne 420 übertragen werden; dieses Token kann mittels einer HTTP-Umleitung über den Browser des Benutzers oder durch direkten Aufruf der Anforderung auf dem Kontaktserver 422 (über HTTP oder SOAP-over-HTTP) im Namen des Benutzers gesendet werden, der in dem Token angegeben ist, welches von dem vertrauenswürdigen Proxy 414 geliefert wurde.
Der Kontaktserver 422 empfängt die Anforderung zusammen mit dem im Verbund gültigen Einmalanmelde-Token und ruft den vertrauenswürdigen Proxy 424 auf. Der vertrauenswürdige Proxy 424 empfängt das im Verbund gültige Einmalanmelde-Token und prüft es auf Gültigkeit, und unter der Annahme, dass das Token gültig und vertrauenswürdig ist, erzeugt er ein lokal gültiges Token für den Benutzer. Der vertrauenswürdige Proxy 424 schickt das lokal gültige Token an den Kontaktserver 422 zurück, der eine Sitzung für den Benutzer in der Domäne 420 aufbaut. Bei Bedarf kann der Kontaktserver 422 eine Einmalanmeldeoperation im Verbund an einem anderen Verbundpartner einleiten.
Die Prüfung des Token auf Gültigkeit in der Domäne 420 wird von dem vertrauenswürdigen Proxy 424 vorgenommen, möglicherweise mit Hilfe eines Sicherheitstoken-Dienstes. In Abhängigkeit von der Art des von der Domäne 410 übergebenen Token muss der Sicherheitstoken-Dienst gegebenenfalls auf eine Benutzer-Registrierdatenbank in der Domäne 420 zugreifen. Beispielsweise kann die Domäne 420 ein binäres Sicherheits-Token bereitstellen, das den Namen und das Passwort des Benutzers enthält, die gegen die Benutzer-Registrierdatenbank in der Domäne 420 validiert werden müssen. Daher prüft ein Unternehmen in diesem Beispiel einfach das Sicherheits-Token von einem Verbundpartner auf Gültigkeit. Die Vertrauensbeziehung zwischen den Domänen 410 und 420 gewährleistet, dass das von der Domäne 410 im Namen des Benutzers übergebene Sicherheits-Token für die Domäne 420 verständlich ist und sie ihm vertrauen kann.
Eine Einmalanmeldeoperation im Verbund setzt nicht nur voraus, dass das Sicherheits-Token, das einer sich auf die Vertrauenswürdigkeit verlassenden Domäne im Namen des Benutzers übergeben wird, auf Gültigkeit geprüft wird, sondern auch, dass eine lokal gültige Benutzerkennung in der sich auf die Vertrauenswürdigkeit verlassenden Domäne auf der Grundlage von Daten, die in dem Sicherheits-Token enthalten sind, ermittelt wird. Ein Ergebnis einer direkten Vertrauensbeziehung und der Geschäftsvereinbarungen, die zur Herstellung einer solchen Beziehung notwendig sind, ist, dass mindestens eine Partei, entweder die ausgebende Domäne oder die sich auf die Vertrauenswürdigkeit verlassende Domäne oder beide, wissen, wie die von der ausgebenden Domäne bereitgestellten Daten in eine Kennung umzusetzen ist, die in der sich auf die Vertrauenswürdigkeit verlassenden Domäne gültig ist. In dem vorstehenden kurzen Beispiel wurde davon ausgegangen, dass die ausgebende Domäne, d. h. die Domäne 410, der sich auf die Vertrauenswürdigkeit verlassenden Domäne, d. h. der Domäne 420, eine Benutzerkennung bereitstellen kann, die in der Domäne 420 gültig ist. In diesem Szenario musste die sich auf die Vertrauenswürdigkeit verlassende Domäne keine Funktion zur Identitätsabbildung aufrufen. Der vertrauenswürdige Proxy 424 in der Domäne 420 erzeugt ein Sicherheits-Token für den Benutzer, der für diesen Nutzer "bürgt". Die verschiedenen Arten der Token, die akzeptiert werden, die Signaturen, die auf Token erforderlich sind, und andere Erfordernisse werden alle als Teil der Geschäftsvereinbarungen des Verbunds vorher festgelegt. Die Regeln und Algorithmen, die die Umsetzung von Kennungen steuern, werden als Teil der Geschäftsvereinbarungen des Verbunds ebenfalls vorher festgelegt. Im Falle einer direkten Vertrauensbeziehung zwischen zwei Teilnehmern wurden die Algorithmen für die Umsetzung von Kennungen für diese beiden Parteien festgelegt, und sie sind gegebenenfalls nicht für andere Parteien in dem Verbund maßgeblich.
Es ist jedoch nicht immer der Fall, dass die ausgebende Domäne weiß, wie sie den Benutzer von einer lokalen Kennung für die Domäne 410 in eine lokale Kennung für die Domäne 420 abbilden soll. In manchen Fällen ist es möglicherweise die sich auf die Vertrauenswürdigkeit verlassende Domäne, die weiß, wie diese Abbildung vorgenommen wird, während in noch anderen Fällen keine der Parteien weiß, wie diese Umsetzung zu erfolgen hat, wobei in diesem Fall gegebenenfalls eine dritte Partei in Form von einem vertrauenswürdigen Vermittler aufgerufen werden muss. Anders ausgedrückt, im Falle einer über einen Vermittler hergestellten Vertrauensbeziehung unterhalten die ausgebende Domäne und die sich auf die Vertrauenswürdigkeit verlassende Domäne keine direkte Vertrauensbeziehung zueinander. Sie haben jedoch eine direkte Vertrauensbeziehung zu einem vertrauenswürdigen Vermittlers wie beispielsweise zu dem vertrauenswürdigen Vermittler 450. Die Regeln und Algorithmen für die Abbildung von Kennungen wurden als Teil dieser Beziehung festgelegt, und der vertrauenswürdige Vermittler verwendet diese Informationen, um bei der Umsetzung von Kennungen, die für eine vermittelte Vertrauensbeziehung notwendig ist, Hilfe zu leisten.
Die Domäne 420 empfängt das von der Domäne 410 ausgegebene Token am Kontaktserver 422, der den vertrauenswürdigen Proxy 424 aufruft, um das Token auf Gültigkeit zu prüfen und um die Identitäten abzubilden. Da der vertrauenswürdige Proxy 424 in diesem Fall den Benutzer von einer lokalen Kennung für die Domäne 410 nicht in eine lokale Kennung für die Domäne 420 abbilden kann, ruft er den vertrauenswürdigen Vermittler 450 auf, der das Token auf Gültigkeit prüft und die Abbildung der Kennungen durchführt. Nachdem er die lokale Kennung für den Benutzer erhalten hat, kann der vertrauenswürdige Proxy 424, möglicherweise über seinen Sicherheitstoken-Dienst, lokale Token erzeugen, die von den nachgeschalteten Anwendungen in der Domäne 420 benötigt werden, z. B. kann ein Kerberos-Token notwendig sein, um eine Einmalanmeldung von dem Kontaktserver zum Anwendungsserver zu vereinfachen. Nach dem Erhalt eines lokal gültigen Token, sofern dies erforderlich ist, kann der Kontaktserver eine lokale Sitzung für den Benutzer aufbauen. Der Kontaktserver ist auch für die grobe Genehmigung von Benutzeranforderungen zuständig und leitet die genehmigten Anforderungen an die entsprechenden Anwendungsserver in der Domäne 420 weiter.
Die Sitzung eines Benutzers wird beendet, wenn er sich abmeldet. Wenn sich ein Benutzer aus einer Sitzung mit seiner Heimdomäne abmeldet, benachrichtigt die Heimdomäne alle sich auf die Vertrauenswürdigkeit verlassenden Domänen, d. h. diejenigen Domänen, an die sie ein Sicherheits-Token ausgegeben hat, und ruft einen Abmeldevorgang des Benutzers in diesen Domänen auf. Wenn eine dieser sich auf die Vertrauenswürdigkeit verlassenden Domänen wiederum die Funktion einer ausgebenden Domäne für denselben Benutzer hat, würde sie stufenweise auch alle ihre sich auf die Vertrauenswürdigkeit verlassenden Domänen über die Abmeldeanforderung des Benutzers benachrichtigen. Der vertrauenswürdige Proxy in jeder Domäne wäre für die Benachrichtigung aller sich auf die Vertrauenswürdigkeit verlassenden Domänen der Abmeldeanforderung des Benutzers verantwortlich, und als Teil dieses Prozesses ruft er gegebenenfalls den vertrauenswürdigen Vermittler auf.
Lebenszyklusverwaltung des Benutzers im Verbund
Ein Teil der vorstehenden Beschreibung der 2A bis 4 erklärte den Aufbau von Komponenten, die in einer Verbundumgebung eingesetzt werden können, während andere Teile die Prozesse zur Unterstützung von Einmalanmelde-Operationen in der gesamten Verbundumgebung erklärten. Diensteanbieter oder sich auf die Vertrauenswürdigkeit verlassende Domänen innerhalb einer Verbundumgebung brauchen nicht unbedingt die Anmeldedaten eines Benutzers verwalten, und diese sich auf die Vertrauenswürdigkeit verlassenden Domänen können ein einziges Einmalanmelde-Token wirksam einsetzen, das vom Identitätsanbieter oder der Heimdomäne des Benutzers bereitgestellt wird. Die vorstehende Beschreibung der 2A bis 4 erklärt jedoch nicht einen bestimmten Prozess, mittels dem die Lebenszyklusverwaltung des Benutzers im Verbund auf vorteilhafte Weise in den Verbunddomänen von Verbundpartnern durchgeführt werden kann.
Die Funktionalität/der Dienst zur Lebenszyklusverwaltung des Benutzers im Verbund umfasst Funktionen zur Unterstützung oder Verwaltung von Verbundoperationen in Bezug auf die jeweiligen Benutzerkonten oder Benutzerprofile eines bestimmten Benutzers in mehreren Verbunddomänen; in manchen Fallen sind die Funktionen oder die Operationen auf eine bestimmte Verbundsitzung für den Benutzer beschränkt. Anders ausgedrückt, die Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund bezieht sich auf die Funktionen, die die Verwaltung von Verbundoperationen über eine Vielzahl von Verbundpartnern hinweg, unter Umständen nur während des Lebenszyklus einer einzigen Benutzersitzung, in einer Datenverarbeitungs-Verbundumgebung ermöglichen.
Jede Verbunddomäne könnte hinsichtlich der Funktionen in jeder einzelnen Verbunddomäne ein Benutzerkonto, ein Benutzerprofil oder irgendeine Art einer Benutzersitzung verwalten. Beispielsweise verwaltet eine bestimmte Verbunddomäne möglicherweise kein lokales Benutzerkonto oder Benutzerprofil in der jeweiligen Verbunddomäne, aber die Verbunddomäne könnte nach erfolgreicher Durchführung einer Einmalanmeldeoperation in der Verbunddomäne eine lokale Benutzersitzung für eine Verbundtransaktion verwalten. Als Teil der Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund, die von dieser bestimmten Verbunddomäne unterstützt wird, kann die Verbunddomäne an einer Einmalabmeldeoperation teilnehmen, die es der Verbunddomäne ermöglicht, die lokale Benutzersitzung zu beenden, nachdem die Verbundtransaktion abgeschlossen ist, wodurch die Sicherheit erhöht und eine wirksame Nutzung der Ressourcen gefördert wird.
In einem weiteren Beispiel über die Nutzung der Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund kann ein Benutzer eine Online-Transaktion tätigen, die die Teilnahme von mehreren Verbunddomänen voraussetzt. Eine Verbunddomäne könnte ein Benutzerprofil lokal verwalten, um die Erfahrung des Benutzers in Bezug auf die Verbunddomäne während einer jeden der Verbundsitzungen des Benutzers, die die Verbunddomäne einschließen, individuell zu gestalten. Als Teil der Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund, die von dieser bestimmten Verbunddomäne unterstützt wird, können die Daten des lokalen Benutzerprofils in der Verbunddomäne während einer bestimmten Verbundtransaktion nahtlos mit Daten von anderen Profilen in anderen Verbunddomänen, die an der jeweiligen Verbundtransaktion beteiligt sind, zusammengeführt und verwendet werden. Die Daten aus den diversen lokalen Benutzerprofilen des Benutzers könnten zum Beispiel in einer bestimmten Zusammenführungsoperation miteinander verknüpft werden, so dass die Daten des Benutzers diesem visuell, d. h. auf einer Webseite, in einer Weise präsentiert werden, dass sich der Benutzer der verschiedenen Ursprungsorte oder Quellen seiner Daten nicht bewusst ist.
Die Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund kann auch Funktionen zur Verknüpfung von Konten/zur Aufhebung dieser Verknüpfung umfassen. Ein Benutzer erhält eine einheitliche, eindeutige Benutzerkennung für alle Verbundpartner, was eine Einmalanmeldung und den Abruf von Attributen (bei Bedarf) über einen Benutzer als Teil der Erfüllung einer Anforderung an einem Verbundpartner ermöglicht. Außerdem kann der Verbundpartner weitere Attribute von einem Identitätsanbieter anfordern, indem er mittels der einheitlichen und eindeutigen Benutzerkennung anonym auf den Benutzer verweist.
Nachdem vorstehend einige unterschiedliche Beispiele für Operationen erwähnt wurden, die mit Hilfe der Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund durchgeführt werden können, veranschaulichen die nachfolgenden verbleibenden Figuren die Art und Weise, in der diese Funktionalität vorteilhaft bereitgestellt und unterstützt werden kann.
Nun Bezug nehmend auf 5 zeigt ein Blockschaubild einige der Komponenten in einer Verbunddomäne zur Umsetzung der Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund gemäß einer Ausführungsform der vorliegenden Erfindung.
5 zeigt Elemente in einer einzigen Verbunddomäne wie zum Beispiel der Verbunddomäne, die von dem in 2C gezeigten Unternehmen 250 betrieben wird. Einige der Elemente in 5 sind ähnlich oder genau gleich wie Elemente, die vorstehend mit Bezug auf andere Figuren wie zum Beispiel 2B erörtert wurden: Der Kontaktserver/Dienst 502 ist gleich dem Kontaktsserver 242; die Anwendungsserver 504, d. h. die Ressourcen-Steuerungsdienste, sind gleich den Anwendungsservern 234; die geschützten oder kontrollierten Ressourcen 506 sind gleich den geschützten Ressourcen 235; und die Anwendung 508 zur Lebenszyklusverwaltung des Benutzers im Verbund (federated user lifecycle management (FULM)) ist gleich dem Server 246 zur Lebenszyklusverwaltung des Benutzers im Verbund. In 2B wurden keine Zugangsschutzsysteme (Firewalls) gezeigt, in 5 hingegen werden Firewalls gezeigt. Die Firewall 510 und die Firewall 512 erzeugen eine externe DMZ (electronic DeMilitarized Zone (elektronische entmilitarisierte Zone)), die die Datenverarbeitungsumgebung des Unternehmens vor Bedrohungen von außerhalb der Domäne des Unternehmens, die beispielsweise über das Internet eindringen, schützt.
Die verschiedenen Perspektiven, die in 5 und 2B gezeigt sind, sind weder unvereinbar noch dienen sie unterschiedlichen Zwecken. Im Gegensatz zu dem in 5 dargestellten Beispiel zeigt 2B nicht die Firewalls, aber dennoch befindet sich der Kontaktserver 242 in dem vorgeschalteten Verbundverarbeitungssystem 240; darüber hinaus ist der Server zur Lebenszyklusverwaltung des Benutzers im Verbund 246 in dem vorgeschalteten Verbundverarbeitungssystem enthalten 240. In 5 ist der Kontaktserver 502 als in der DMZ zwischen den Firewalls 510 und 512 befindlich gezeigt, die ein der Unternehmensdomäne vorgeschaltetes elektronisches oder physisches Verarbeitungssystem bilden; überdies befindet sich die Anwendung/der Dienst 508 zur Lebenszyklusverwaltung des Benutzers im Verbund elektronisch hinter der Firewall 512. Die verschiedenen Perspektiven lassen sich vereinbaren, wenn man das vorgeschaltete Verbundverarbeitungssystem 240 und das nachgeschaltete Verarbeitungssystem 230 in 2B als einen logischen Aufbau von Komponenten betrachtet, während man die DMZ und die anderen Komponenten in 5 als Komponenten ansieht, die ein vorgeschaltetes physisches oder elektronisches Verarbeitungssystem und ein nachgeschaltetes physisches oder elektronisches Verarbeitungssystem bilden, die beide Verbundkomponenten enthalten können.
Betrachtet man noch einmal die Rollen einer Kontakteinheit/eines Kontaktdienstes, sieht die Kontakteinheit die Sitzungsverwaltung vor, zumindest in Bezug auf den Dialogverkehr eines Benutzers mit der Verbundfunktionalität in der Datenverarbeitungsumgebung eines Unternehmens; Anwendungen in einem älteren nachgeschalteten System der Datenverarbeitungsumgebung des Unternehmens können auch ihre eigene Funktionalität zur Sitzungsverwaltung realisieren.
Unter der Annahme, dass ein Unternehmen Richtlinien-Funktionalität in Bezug auf die Datenverabeitungs-Verbundumgebung ausführt, kann die Kontakteinheit die Funktion einer Stelle zur Durchsetzung der Richtlinien für die Richtlinien-Entscheidungsstelle eines anderen Verbundpartners übernehmen. Geht man ferner davon aus, dass dies in Anbetracht der gegebenen Art der Ausführung der Verbundfunktionalität zulässig ist, ist die Kontakteinheit für das Einleiten einer gegen einen Benutzer gerichteten Identitätsprüfungsoperation in denjenigen Szenarien verantwortlich, in denen keine Einmalanmeldeoperation zur Anwendung kommt. Als solches kann die Kontakteinheit in einer Vielzahl von Formen, beispielsweise in Form eines umgekehrten Proxy-Servers, eines Webserver-Zusatzprogramms oder in anderer Weise, realisiert werden. Die Funktionalität der Kontaktstelle kann auch in einem Anwendungsserver selbst realisiert werden, wobei sich die Dienste zur Lebenszyklusverwaltung des Benutzers im Verbund in diesem Fall in der DMZ befinden können.
Nochmals Bezug nehmend auf 5 umfasst die Anwendung 508 zur Lebenszyklusverwaltung des Benutzers im Verbund auch eine besonders hervorzuhebende Unterstützungsfunktion, die dazu dient, mit Einschüben 514 zur Lebenszyklusverwaltung des Benutzers im Verbund, die in 2B nicht gezeigt sind, eine Verbindung herzustellen, in Dialog zu treten oder in anderer Weise zusammenzuarbeiten. In einer Ausführungsform der vorliegenden Erfindung stellen die Verbundprotokolllaufzeit-Einschübe die Funktionalität für verschiedene Arten von unabhängig voneinander veröffentlichten oder entwickelten Standards oder Profilen zur Lebenszyklusverwaltung des Benutzers im Verbund bereit, wie zum Beispiel: WS-Federation Passive Client; Liberty Alliance ID-FF Single Sign On (B/A, B/P and LECP); Register Name Identifier; Federation Termination Notification; and Single Logout.
In einer beispielhaften Ausführungsform der vorliegenden Erfindung kann auf einen Satz von Protokollen an verschiedenen URIs zugegriffen werden. Durch diese Vorgehensweise kann die Anwendung zur Lebenszyklusverwaltung des Benutzers im Verbund gleichzeitig mehrere Standards oder Spezifikationen der Lebenszyklusverwaltung des Benutzers im Verbund, z. B. die Spezifikation für Webdienste, WS-Federation, gegenüber den Spezifikationen der Liberty Alliance, in einer einzigen Anwendung unterstützen und dadurch die Konfigurationsauswirkungen auf die Gesamtumgebung zur Unterstützung von mehreren Verbundprotokollen so gering wie möglich halten.
Genauer gesagt, die entsprechende Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund wird vom Kontaktserver aufgerufen, indem er Benutzeranforderungen erforderlichenfalls an die Anwendung zur Lebenszyklusverwaltung des Benutzers im Verbund umleitet und/oder weiterleitet. Nochmals Bezug nehmend auf 5 empfängt der Kontaktserver 502 Benutzeranforderungen 520, die anschließend ausgewertet werden, um die Art der empfangenen Anforderung festzustellen, wobei diese von der Art der Anforderungsnachricht, die empfangen wurde, angegeben oder durch Ermittlung der Ziel-URI in der Anforderungsnachricht festgestellt werden könnte. Während Anforderungen 522 für geschützte Ressourcen weiterhin an die Anwendungsserver 504 geleitet werden, werden Anforderungen 524 für Funktionen zur Lebenszyklusverwaltung des Benutzers im Verbund, z. B. eine Anforderung für den Aufruf einer Einmalanmeldeoperation, an die Anwendung 508 zur Lebenszyklusverwaltung des Benutzers im Verbund weitergereicht, die bei Bedarf das geeignete Zusatzprogramm zur Lebenszyklusverwaltung des Benutzers im Verbund aufruft, um die empfangene Anforderung zu erfüllen. Wenn ein neues Verbundprotokoll oder eine neue Verbundfunktion festgelegt oder wenn ein bereits vorhandenes Protokoll oder eine bereits vorhandene Funktion in irgendeiner Weise geändert oder verfeinert wird, kann einfach ein neues Hilfemodul eingesteckt und damit eine Hilfefunktion bereitgestellt werden, oder die Hilfefunktion kann verfeinert werden, indem an einem zuvor installierten Zusatzprogramm Änderungen vorgenommen werden.
Die in 5 dargestellte beispielhafte Ausführungsart einer Anwendung zur Lebenszyklusverwaltung des Benutzers im Verbund zeigt, dass die Anwendung zur Lebenszyklusverwaltung des Benutzers im Verbund gleichzeitig mehrere Funktionen zur Lebenszyklusverwaltung des Benutzers im Verbund unterstützen kann, wobei sie die Eigenschaft aufweist, dass Erweiterungen eingesteckt werden können, so dass die Anwendung bei Bedarf mittels eines Zusatzprogramms um neue Funktionen erweitert werden kann, ohne dass irgendwelche Änderungen an der bestehenden Infrastruktur vorgenommen werden müssen. Wenn man beispielsweise davon ausgeht, dass die vorliegende Erfindung unter Verwendung einer auf Java^TM beruhenden Anwendung zur Lebenszyklusverwaltung des Benutzers im Verbund ausgeführt ist, kann der Java^TM CLASSPATH der Anwendung zur Lebenszyklusverwaltung des Benutzers im Verbund um Unterstützung für ein neues Verbundprotokoll, beispielsweise ein neu veröffentlichtes Protokoll zur Einmalanmeldung, erweitert werden, indem neu entwickelte Java^TM-Klassen konfiguriert werden, wobei diese neuen Klassen gemäß einer Ausführungsform den neuen Standard zusammen mit der Protokollschnittstelle der vorliegenden Erfindung unterstützen.
Die vorliegende Erfindung setzt die vorhandene Umgebung, in die eine Lösung zur Lebenszyklusverwaltung des Benutzers im Verbund eingebunden werden soll, vorteilhaft ein. Die Anwendung zur Lebenszyklusverwaltung des Benutzers im Verbund lässt sich ohne weiteres ändern, um neue Protokolle/Standards zu unterstützen, das ihre Entwicklung mit nur geringfügigen Änderungen an der Gesamtinfrastruktur auskommt. Alle Änderungen, die gegebenenfalls notwendig sind, um eine neue Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund zu unterstützen, werden fast ausschließlich an der Anwendung zur Lebenszyklusverwaltung des Benutzers im Verbund vorgenommen, so dass diese Anwendung so konfiguriert werden müsste, dass sie die erweiterte Funktionalität versteht.
Möglicherweise müssen an anderen Verbundkomponenten geringfügige Konfigurationsänderungen vorgenommen werden, z. B. an einem Kontaktserver, damit die Gesamtinfrastruktur die neuen Funktionen zur Lebenszyklusverwaltung des Benutzers im Verbund aufrufen und gleichzeitig die bestehende Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund weiterhin unterstützen kann. Die Anwendungen zur Lebenszyklusverwaltung des Benutzers im Verbund sind funktional jedoch unabhängig von den restlichen Verbundkomponenten, da diese Anwendungen gegebenenfalls nur eine sehr geringe Interaktion mit anderen Verbundkomponenten der Verbundumgebung erforderlich machen. In einer beispielhaften Ausführungsform kann die Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund beispielsweise in einen unternehmensbasierten Datenspeicher, z. B. einen LDAP-Datenspeicher, eingebunden werden, wenn Daten zur Lebenszyklusverwaltung des Benutzers im Verbund, wie zum Beispiel NameIdentifier-Werte gemäß den Liberty-Alliance-Profilen, in einem Datenspeicher zur Lebenszyklusverwaltung des Benutzers im Verbund, auf den extern zugegriffen werden kann, und nicht in einem privaten, internen Datenspeicher zur Lebenszyklusverwaltung des Benutzers im Verbund, der für externe Einheiten nicht erkennbar oder zugänglich ist, gespeichert werden müssen.
Folglich müssen an einer bestehenden Umgebung nur geringfügige Änderungen vorgenommen werden, um die Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund zu unterstützen, wenn sie gemäß einer Ausführungsform der vorliegenden Erfindung ausgeführt ist. Überdies wirken sich Änderungen an der Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund, einschließlich des Hinzufügens von neuen Funktionen, kaum spürbar auf eine bestehende Verbundumgebung aus. Wenn ein neuer Standard bezüglich der Einmalanmeldung veröffentlicht wird, kann eine Unterstützungsfunktion für diesen Standard folglich ohne weiteres hinzugefügt werden.
Die herkömmliche Identitätsprüfung von Benutzern schließt lediglich einen Dialog zwischen der Datenverarbeitungsumgebung eines Unternehmens und dem Endbenutzer ein; die Art und Weise, in der das Unternehmen diesen Austausch zum Zweck der Identitätsprüfung realisieren möchte, ist von dem Unternehmen frei wählbar und hat keinerlei Auswirkungen auf ein anderes Unternehmen. Wenn bei der Einmalanmeldung jedoch eine Verbundfunktionalität oder eine domänenübergreifende Funktionalität unterstützt werden soll, müssen Geschäftspartner miteinander kommunizieren. Dieses Erfordernis lässt sich nicht mit unternehmenseigenen Protokollen skalierbar erfüllen. Obgleich die direkte Erweiterung einer Kontakteinheit um eine Unterstützungsfunktion für auf einem Standard beruhende Verbundprotokolle als eine robuste Lösung erscheint, müssen an der Kontakteinheit, bei der es sich um eine bereits vorhandene Komponente in der Datenverarbeitungsumgebung des Unternehmens handelt, Änderungen vorgenommen werden; diese Änderungen müssen jedoch jedes Mal vorgenommen werden, wenn sich eines dieser öffentlichen Verbundprotokolle ändert.
Die vorliegende Erfindung sieht vorzugsweise einen modulareren Ansatz vor, indem sie diese Funktionalität aus der Kontakteinheit auslagert. Die Kontakteinheit muss sich jedoch auch mit häufigen Änderungen an diesen öffentlichen Protokollen befassen, und dadurch, dass man diese Funktionalität in Form von einem Zusatzprogramm bereitstellt, lassen sich ein Wechsel zu diesen Protokollen oder Aktualisierungen dieser Protokolle ohne weiteres durchführen.
Funktionale Unterstützung zur Lebenszyklusverwaltung des Benutzers im Verbund
Standardbasierte Lösungen zur Einmalanmeldung nach dem Stand der Technik wie zum Beispiel die WS-Federation-Spezifikation oder die Liberty-Alliance-ID-FF-Profile sehen Modelle vor, die bis zu einem gewissen Grad eine Lebenszyklusverwaltung des Benutzers im Verbund ermöglichen. Diese Spezifikationen sind öffentlich verfügbar und können von unabhängigen Anbietern und Firmen eingesetzt werden. Diese Spezifikationen nach dem Stand der Technik befassen sich jedoch nicht mit der Art und Weise, in der eine bestehende Umgebung geändert werden muss, um die in den Spezifikationen angegebene Funktionalität einzubinden; diese Spezifikationen nach dem Stand der Technik wirken sich dahingehend aus, dass die Änderungen, die an der Infrastruktur von bestehenden Datenverarbeitungsumgebungen durchgeführt werden müssten, um die angegebene Funktionalität zu integrieren, gegebenenfalls verhindern, dass diese Spezifikationen übernommen wird. Bei allen unternehmenseigenen Lösungen bezüglich der Einmalanmeldung war dies beispielsweise der Fall.
Im Gegensatz dazu stellt die vorliegende Erfindung vorzugsweise Verfahren und Systeme zur Einbindung dieser Funktionalität bereit, um Verbundspezifikationen so umzusetzen, dass nur geringfügige Änderungen an der Infrastruktur von bestehenden Datenverarbeitungsumgebungen vorgenommen werden müssten, wie vorstehend bereits erörtert wurde. Dies gilt auch für die Einbindung der Funktionalität zur Unterstützung der Lebenszyklusverwaltung des Benutzers im Verbund. 2B und 5 zeigen Beispiele für den logischen Aufbau von Komponenten, die zur Realisierung einer Ausführungsform der vorliegenden Erfindung hinsichtlich der Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund verwendet werden können, 6 zeigt dagegen einen Prozess, durch den die Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund gemäß einer Ausführungsform der vorliegenden Erfindung aktiviert werden kann.
Zudem stellt 6 einen Prozess dar, der es ermöglicht, die Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund in einer Weise umzusetzen, die unabhängig von der Art und Weise ist, in der die Funktionalität der Kontaktstelle in einer Verbunddomäne umgesetzt wird. Eine Funktionseinheit in Form von einer Kontaktstelle entspricht einer Einheit, die Sitzungen für einen Benutzer/Client verwalten kann. Die Sitzungsverwaltung beinhaltet den Aufbau einer Sitzung auf der Grundlage von einer bestimmten Form von Daten, sei es eine zuvor erfolgreich stattgefundene direkte Identitätsprüfungsoperation, eine aktuell erfolgreiche direkte Identitätsprüfungsoperation und/oder eine erfolgreiche Einmalanmeldeoperation; die Sitzungsverwaltung schließt auch andere Operationen ein, die an der Sitzung durchgeführt werden, zu denen optionale Entscheidungen bezüglich der Identitätsprüfung und auch die Beendigung einer Sitzung aufgrund dessen, dass die Sitzung abgelaufen ist oder abgebrochen wurde oder eine Inaktivitäts-Zeitgrenze abgelaufen ist, usw. gehören. Ein Kontaktserver kann weiterhin Unterstützung für Identitätsprüfungsoperationen gewähren, bei denen er eine direkte Challenge/Response-Interaktion mit einem Benutzer durchführt. Die Kontakteinheit kann auch die Funktion einer Stelle zur Durchsetzung der Richtlinien übernehmen und dadurch Identitätsprüfungsdienste als Teil der Sitzungsverwaltung zulassen.
Die Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund sieht Einmalanmeldedienste (zusammen mit anderen Verbundoperationen) vor, da diese Operationen den Dialogverkehr mit dritten Parteien wie zum Beispiel Identitätsanbietern und nicht nur mit Endbenutzern beinhalten; die Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund stützt sich bei Sitzungsverwaltungsdiensten auf den von der Kontaktstelle angebotenen Funktionsumfang. Die Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund setzt einen vertrauenswürdigen Dienst voraus beziehungsweise sie stützt sich auf diesen, der von einer anderen Komponente bereitgestellt wird, wie nachstehend ausführlicher erklärt wird; der vertrauenswürdige Dienst kann als ein lokal gesonderter Dienst ausgeführt sein, der verteilte Komponenten oder eine logisch getrennte Komponente beinhaltet, die zusammen mit den Komponenten zur Lebenszyklusverwaltung des Benutzers im Verbund untergebracht ist, oder alternativ dazu kann der vertrauenswürdige Dienst zusammen mit den Komponenten zur Lebenszyklusverwaltung des Benutzers im Verbund als Teil einer einzelnen Anwendung, z. B. einer EAR-Datei, ausgeführt sein.
Zwar wurde bei der vorausgehenden Erörterung der vorstehenden Figuren ein funktionsspezifischer Kontaktserver beschrieben, der in einer Verbunddomäne unterstützt wird, doch erfordert der mit Bezug auf 6 beschriebene Prozess keinen funktionsspezifischen Kontaktserver. In der in 6 gezeigten Ausführungsform der vorliegenden Erfindung können die Funktionen der Kontaktstelle mit Hilfe einer beliebigen Anwendung oder einer anderen Einheit, die die Funktionalität der Kontaktstelle bereitstellt, ausgeführt werden; die Kontaktanwendung kann ein umgekehrter Proxy-Server, ein Webserver, ein Zusatzprogramm für einen Webserver, ein Servlet-Filter oder eine andere Art eines Servers oder ein einer Anwendung sein. Um die Funktionalität der Kontaktstelle, die nachstehend mit Bezug auf den beispielhaften Prozess zur Ausführung der nachfolgenden Ausführungsformen beschrieben wird, von dem vorstehend beschriebenen Kontaktserver zu unterscheiden, wird die Funktionalität der Kontaktstelle nachfolgend als Kontakteinheit oder Kontaktdienst bezeichnet.
Es sei angemerkt, dass 6 zwar eine Einmalanmeldeoperation in einer Datenverarbeitungs-Verbundumgebung zeigt, ähnliche Prozesse für andere Arten von Verbundoperationen, z. B. eine Einmalabmeldeoperation, gemäß verschiedenen Ausführungsform der vorliegenden Erfindung aber ebenfalls ausgeführt werden könnten.
Nun Bezug nehmend auf 6 zeigt ein Datenflussdiagramm einen Prozess zur Durchführung einer Einmalanmeldeoperation mit Hilfe der Funktionen zur Lebenszyklusverwaltung des Benutzers im Verbund gemäß einer Ausführungsform der vorliegenden Erfindung. 6 zeigt ein Pseudo-UML-Diagramm der Datenflüsse und Interaktionen zwischen einem Identitätsanbieter und einem Diensteanbieter, die Verbundfunktionalität gemäß einer Ausführungsform der vorliegenden Erfindung, insbesondere in Bezug auf eine Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund, die von einer Ausführungsform der vorliegenden Erfindung bereitgestellt wird, unterstützen. Im Allgemeinen beginnt der in 6 gezeigte Prozess, wenn die Kontakteinheit eines Diensteanbieters eine Anforderung für eine geschützte Ressource empfängt, die in der Datenverarbeitungs-Verbundumgebung des Diensteanbieters unterstützt wird. Statt ihre eigenen Verfahren zur Identitätsprüfung aufzurufen, leitet die Kontakteinheit am Diensteanbieter die Anforderung entweder um oder leitet sie weiter oder ruft andernfalls Funktionen auf, um die Erstanforderung an die Anwendung zur Lebenszyklusverwaltung des Benutzers im Verbund zu senden, die in der Datenverarbeitungs-Verbundumgebung eines Identitätsanbieters unterstützt wird. Wie nachstehend ausführlicher erklärt wird, kann die Anwendung zur Lebenszyklusverwaltung des Benutzers im Verbund die korrekte Art und Weise der Identitätsprüfung des Benutzers sowie die korrekte Art und Weise festlegen, in der Daten an die Kontakteinheit zurückgeschickt werden, die von der Kontakteinheit benötigt werden, um eine Sitzung für den Benutzer am Diensteanbieter so einzuleiten und die restliche Transaktion des Benutzers am Diensteanbieter so zu verarbeiten, als hätte der Benutzer eine Identitätsprüfungsoperation direkt mit dem Diensteanbieter durchgeführt.
Der Prozess in 6 beginnt damit, dass die Kontakteinheit am Diensteanbieter eine ursprüngliche Anforderung für eine kontrollierte Ressource von einem Benutzer, dessen Identität noch nicht festgestellt wurde, empfängt (Schritt 602); die ursprüngliche Anforderung kann als Einleitung einer Transaktion für den Benutzer betrachtet werden, obgleich es sich bei der empfangenen Anforderung lediglich um eine von vielen nachgelagerten Transaktionen handeln kann, die eine komplexere Transaktion unterstützen. In einer Ausführungsform stellt der Diensteanbieter gegebenenfalls fest, dass die ursprüngliche Anforderung von einem Benutzer stammt, dessen Identität noch nicht festgestellt wurde, indem er erkennt, dass die Anforderung von einem Endbenutzer oder einer Endanwendung stammt, für den beziehungsweise für die der Diensteanbieter kein Protokoll einer laufenden Sitzung hat.
Die Kontakteinheit erzeugt dann eine Anforderung, die entweder umgeleitet oder weitergeleitet wird, oder sie ruft andernfalls Funktionen auf, um die ursprüngliche Anforderung an die Anwendung zur Lebenszyklusverwaltung des Benutzers im Verbund am Diensteanbieter zu senden (Schritt 604); die Kontakteinheit kann jedes Mittel zum Aufrufen der Funktionen zur Lebenszyklusverwaltung des Benutzers im Verbund verwenden, mit dem diese Funktionen die Antwortnachricht erstellen können, welche an den Identitätsanbieter gesendet werden muss; anders ausgedrückt, die Kontakteinheit braucht keine Funktionen zu integrieren, um diese komplizierten Einmalanmelde-Nachrichten zu bedienen beziehungsweise sie zu beantworten. In dem in 6 gezeigten Beispiel wird die ursprüngliche Anforderung anschließend über die ursprüngliche Anwendung, d. h. eine Browser-Anwendung, die von einem Endbenutzer betrieben wird, an die Anwendung zur Lebenszyklusverwaltung des Benutzers im Verbund am Diensteanbieter umgeleitet (Schritt 606).
Nachdem die Anwendung die Anforderung empfangen hat, ermittelt sie zur Lebenszyklusverwaltung des Benutzers im Verbund am Diensteanbieter den entsprechenden Identitätsanbieter für den Benutzer, indem sie mit der Endbenutzer-Anwendung Daten austauscht (Schritt 608). Dieser Schritt ist optional; unter der Voraussetzung, dass der Identitätsanbieter ein Verbundpartner des Diensteanbieters in einer bestimmten Datenverarbeitungs-Verbundumgebung ist, kann der Diensteanbieter bereits mit Daten für den Standort oder mit den Kontaktdaten der Kontakteinheit am Identitätsanbieter, z. B. einer URL, konfiguriert sein; alternativ dazu kann der Diensteanbieter eine Nachschlageoperation durchführen, um den Standort oder die Kontaktdaten der Kontakteinheit am Identitätsanbieter zu erhalten, nachdem er die Identität des jeweiligen Identitätsanbieters ermittelt hat, der für die Transaktion des Endbenutzers verwendet werden soll. In manchen Fällen kennt der Diensteanbieter wahrscheinlich die Identität des zu verwendenden Identitätsanbieters, da der Diensteanbieter ungefähr nur einen Identitätsanbieter kennt, so dass es praktisch keine Auswahl gibt. In anderen Fällen kennt der Diensteanbieter die Identität des Identitätsanbieters möglicherweise aufgrund von bleibenden benutzerseitig verwalteten Daten wie zum Beispiel einem bleibenden HTTP-Cookie. In noch anderen Fällen ist es gegebenenfalls notwendig, dass der Diensteanbieter mit dem Benutzer im Schritt 608 in Dialogverkehr tritt, damit der Benutzer dem Diensteanbieter Daten über die Identität des Identitätsanbieters bereitstellt, die der Benutzer bei der aktuellen Verbundtransaktion verwenden möchte. Sobald der Diensteanbieter über die Identität des Identitätsanbieters verfügt, kann der Diensteanbieter die entsprechende URI für die Einmalanmelde-Funktionalität (oder eine andere Verbundfunktionalität, je nach der Art der Verbundoperation oder der Transaktion, die gerade durchgeführt wird) aus dem jeweiligen Datenspeicher abrufen. Die vorliegende Erfindung ist vorzugsweise auch mit einer anderen Art und Weise der Durchführung des Schritts 608 vereinbar; die Liberty-Alliance-Spezifikationen beschreiben eine Interaktion, bei der der Benutzer tatsächlich mit einer Umleitung an eine andere Website konfrontiert wird, von der Daten von einem Cookie abgerufen werden können (wobei dies aufgrund von Beschränkungen bei Operationen in Bezug auf DNS-Cookies so durchgeführt wird), die dann ohne direktes Eingreifen des Benutzers, d. h., ohne dass der Benutzer Daten in einem HTML-Format bereitstellen muss, an die Funktionskomponente zur Lebenszyklusverwaltung des Benutzers im Verbund zurückgeschickt wird.
Die Lebenszyklusverwaltung des Benutzers im Verbund am Diensteanbieter erzeugt sodann eine Anforderung für eine Funktion oder Operation zur Lebenszyklusverwaltung am Identitätsanbieter und versendet diese (Schritt 610), beispielsweise eine Anforderung zum Erhalt von geeigneten Informationen zum erfolgreichen Ausführen von Einmalanmelde-Operationen.. Die Anforderung kann in ein Sicherheitstoken eingebettet oder von einem Sicherheitstoken begleitet werden, das anzeigt, dass der Identitätsanbieter den übertragenen Daten von dem Diensteanbieter vertrauen kann; vorzugsweise wird Vertrauenswürdigkeit zwischen dem Diensteanbieter und dem Identitätsanbieter durch Signaturen und Verschlüsselung der Anforderungsnachricht erlangt, und ein Sicherheits-Token kann von einem digitalen Zertifikat dargestellt werden, das der Anforderung beiliegt. Der Anforderung für die Operation zur Lebenszyklusverwaltung des Benutzers im Verbund können Daten über die ursprüngliche Anforderung von der Endbenutzer-Anwendung beigefügt sein, da diese Operation auf viele unterschiedliche Arten durchgeführt werden kann, die von der Art der Anforderung abhängen, die die Endbenutzer-Anwendung an den Diensteanbieter gestellt hat.
Die Anforderung für die Funktion oder Operation zur Lebenszyklusverwaltung des Benutzers im Verbund wird empfangen und über die Endbenutzer-Anwendung an die Kontakteinheit am Identitätsanbieter umgeleitet (Schritt 612), wobei die zuvor ermittelten Kontaktdaten für die Kontakteinheit am Identitätsanbieter verwendet werden. Die vorliegende Erfindung ist vorzugsweise mit verschiedenen Arten der Durchführung des Schritts 612 vereinbar; zum Beispiel darf die Art der Umleitung bei den Liberty-Alliance-Spezifikationen einheitenspezifisch sein, und die in der vorliegenden Erfindung enthaltene Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund kann vorzugsweise zwischen einer HTTP-Umleitung als Reaktion auf eine HTTP-Antwort mit dem Statuswert "302" und einer HTTP-Umleitung als Reaktion auf eine HTTP-Antwort mit dem Statuswert "200" (OK) unter Verwendung einer HTTP-POST-Nachricht und auf der Grundlage der Frage, ob es sich um eine Mobileinheit im Gegensatz zum Internet handelt, wechseln.
Nachdem die Kontakteinheit am Identitätsanbieter die Anforderung für die Funktion oder Operation zur Lebenszyklusverwaltung des Benutzers im Verbund empfangen hat, kann die Kontakteinheit am Identitätsanbieter eine optionale Identitätsprüfungsoperation in Bezug auf den Endbenutzer oder die Anwendung des Endbenutzers durchführen (Schritt 614). Eine Identitätsprüfungsoperation ist immer erforderlich, wenn es beim Identitätsanbieter keine gültige Sitzung für den Benutzer gibt; ohne diese kann der Identitätsanbieter zum Zweck einer Einmalanmeldung nicht feststellen, wer der Benutzer ist. Eine Identitätsprüfung kann selbst dann notwendig sein, wenn es eine gültige Sitzung für den Benutzer gibt, um sicherzustellen, dass der Benutzer immer noch aktiv ist oder um eine höhere Ebene der Zugangsdaten nachzuweisen. Es sei angemerkt, dass der Diensteanbieter festlegen kann, dass der Identitätsanbieter keine neue Identitätsprüfungsoperation durchführen soll, so dass die Einmalanmeldeoperation fehlschlagen muss, wenn es keine gültige Sitzung für den Benutzer gibt. Die Art der Identitätsprüfungsoperation kann sich dahingehend unterscheiden, dass sie automatisch durchgeführt werden kann oder aber eine Benutzereingabe, eine Eingabe einer biometrischen oder einer anderen Art von Identitätsprüfungseinheit oder eine Eingabe von einer anderen Datenquelle notwendig machen kann. Wenn zum Beispiel eine hohe Sicherheitsstufe aufrechterhalten werden soll, die gewährleistet, dass der Endbenutzer ein berechtigter Anforderer für die kontrollierte Ressource ist, die in der ursprünglichen Anforderung angegeben wurde, kann eine Identiätsprüfungsoperation erforderlich sein. In einem anderen Szenario kann eine Operation zur Identitätsfeststellung erforderlich sein, die Kontakteinheit am Identitätsanbieter hat jedoch möglicherweise Zugriff auf Informationen, die anzeigen, dass der Identitätsanbieter bereits eine aktive Sitzung für den Endbenutzer unterhält und dadurch das Erfordernis umgeht, am Schritt 614 eine nachfolgende Identitätsprüfungsoperation auszuführen.
Die Kontakteinheit am Identitätsanbieter sendet die empfangene Anforderung für die Funktion oder Operation zur Lebenszyklusverwaltung des Benutzers im Verbund, die von der Anwendung zur Lebenszyklusverwaltung des Benutzers im Verbund am Diensteanbieter gestellt wurde, daraufhin an die Anwendung zur Lebenszyklusverwaltung des Benutzers im Verbund am Identitätsanbieter (Schritt 616). Nachdem die Anwendung die Anforderung ausgewertet hat, erstellt (Schritt 618) sie zur Lebenszyklusverwaltung des Benutzers im Verbund am Identitätsanbieter eine Antwort, die die benutzerspezifischen Daten enthält oder der die benutzerspezifischen Daten beigefügt sind, die die Anwendung zur Lebenszyklusverwaltung des Benutzers im Verbund am Diensteanbieter sucht. Der Identitätsanbieter kann beispielsweise Datenbanken unterstützen, die vertrauliche Identitätsdaten oder andere Attributdaten über den Endbenutzer enthalten, die nicht an anderer Stelle in einer Datenverarbeitungs-Verbundumgebung gespeichert werden. Wie zuvor erwähnt wurde, waren der empfangenen Anforderung für die Operation zur Lebenszyklusverwaltung des Benutzers im Verbund möglicherweise Daten über die ursprüngliche Anforderung von der Endbenutzer- Anwendung beigefügt, da diese Operation auf viele unterschiedliche Arten durchgeführt werden kann, die von der Art der Anforderung abhängen, die die Endbenutzer-Anwendung an den Diensteanbieter gestellt hat. Ebenso kann die Antwort von der Anwendung zur Lebenszyklusverwaltung des Benutzers im Verbund am Identitätsanbieter in einer bestimmten Weise auf die ursprünglich angegebene kontrollierte Ressource zugeschnitten werden.
Die Anwendung zur Lebenszyklusverwaltung des Benutzers im Verbund am Identitätsanbieter sendet anschließend die Antwort an die Endbenutzer-Anwendung (Schritt 620), indem er beispielsweise eine HTTP-POST/Umleitungs-Nachricht verwendet, die die Nachricht sodann an die Anwendung zur Lebenszyklusverwaltung des Benutzers im Verbund am Diensteanbieter umleitet (Schritt 622) Es sei angemerkt, dass der Identitätsanbieter einfach einen Zeiger oder eine ähnliche Art eines indirekten Verweisdatenelements zurückschicken kann, der auf die Daten zeigt, die der Diensteanbieter erwartet; in diesem Fall muss der Diensteanbieter den empfangenen Zeiger (der auch als ein Artefakt bekannt ist) verwenden, um die Daten abzurufen, zum Beispiel, indem er über den Rückkanal eine Anforderung an den Identitätsanbieter stellt, um die benutzerspezifischen Daten abzurufen, die von dem Diensteanbieter verwendet werden sollen.
Unter der Annahme, dass die empfangene Nachricht keinen Fehlercode enthält oder in anderer Weise anzeigt, dass die Anwendung zur Lebenszyklusverwaltung des Benutzers im Verbund am Identitätsanbieter die angeforderte Funktion oder Operation zur Lebenszyklusverwaltung des Benutzers im Verbund nicht erfolgreich ausführen konnte, entnimmt die Anwendung zur Lebenszyklusverwaltung des Benutzers im Verbund am Diensteanbieter der empfangenen Antwort die von ihr benötigten Daten und erstellt eine Antwort für die Kontakteinheit am Diensteanbieter (Schritt 624). Die Anwendung zur Lebenszyklusverwaltung des Benutzers im Verbund am Diensteanbieter sendet dann die erzeugte Antwort in irgendeiner Weise an die Kontakteinheit am Diensteanbieter beziehungsweise schickt diese Antwort zurück (Schritt 626).
Die Anwendung zur Lebenszyklusverwaltung des Benutzers im Verbund kann in Form einer Java^TM-Anwendung, z. B. als eine EAR-Datei, realisiert werden, die hinter einer Firewall in einer Domäne installiert wird. Die Eigenschaften der Antwort, die an die Kontakteinheit zurückgeschickt wird, können als Teil der Installation und Konfiguration der Anwendung zur Lebenszyklusverwaltung des Benutzers im Verbund konfiguriert werden; daher ist diese Anwendung nicht von der Form der Kontakteinheit abhängig. Anders ausgedrückt, die Anwendung zur Lebenszyklusverwaltung des Benutzers im Verbund hängt mit Ausnahme der Informationen, die sie ausweisen beziehungsweise ihren Standort angeben, nicht von der Art der Kontakteinheit ab, d. h., der Art und Weise, in der die Transaktionssteuerung an sie zurückgegeben wird, und dem Informationsgehalt, den sie bei Rückgabe der Transaktionssteuerung benötigt. Durch diesen Lösungsansatz werden die Auswirkungen auf die bestehende Infrastruktur der Datenverarbeitungsumgebung des Verbundpartners auf ein Mindestmaß verringert, da es möglich ist, beliebige Funktionen zur Lebenszyklusverwaltung des Benutzers im Verbund, beispielsweise Einmalanmeldeoperationen, Einmalabmeldeoperationen, die Verknüpfung von Konten, die Aufhebung dieser Verknüpfung usw., von den Funktionen der Sitzungsverwaltung, die die Kontakteinheit bietet, zu entkoppeln.
Wenn man davon ausgeht, dass die Kontakteinheit am Diensteanbieter eine erfolgreiche Antwort von der Anwendung zur Lebenszyklusverwaltung des Benutzers im Verbund am Diensteanbieter empfängt, geht die Kontakteinheit am Diensteanbieter dazu über, die ursprüngliche Anforderung von der Endbenutzer-Anwendung zu verarbeiten (Schritt 628), wobei die Verarbeitung in diesem Beispiel den Aufbau einer Benutzersitzung, die Durchführung von optionalen Zugriffs- oder Identitätsprüfungs-Steuerungsoperationen und das anschließende Versenden oder Weiterleiten einer Anforderung für den Zugriff auf eine kontrollierte Ressource an einen nachgeschalteten Anwendungsserver, der den Zugriff auf die kontrollierte Ressource verwaltet oder diesen Zugriff in anderer Weise ermöglicht (Schritt 630), beinhaltet, wodurch der Prozess beendet wird.
Fasst man das in 6 gezeigte Beispiel zusammen, lässt sich sagen, dass die Identität des Endbenutzers gegenüber dem Diensteanbieter nicht nachgewiesen worden wäre, wenn die ursprüngliche Anforderung an der Kontakteinheit des Diensteanbieters empfangen worden wäre. Statt eine Identitätsprüfungsoperation vom Diensteanbieter gesteuert direkt durchzuführen, verweist der Diensteanbieter auf einen Identitätsanbieter, um eine Einmalanmeldeoperation im Verbund durchzuführen. Die Kontakteinheit am Diensteanbieter wartet auf einen Hinweis/eine Nachricht, dass die Einmalanmeldeoperation im Verbund über Anwendungen zur Lebenszyklusverwaltung des Benutzers im Verbund am Diensteanbieter und am Identitätsanbieter, die in einer Datenverarbeitungs-Verbundumgebung Partner sind, erfolgreich durchgeführt worden ist. Nachdem die Kontakteinheit am Diensteanbieter einen Hinweis/eine Nachricht empfangen hat, dass die Einmalanmeldeoperation im Verbund erfolgreich durchgeführt worden ist, wird die ursprüngliche Anforderung anschließend weiter verarbeitet.
Die vorliegende Erfindung setzt die vorhandene Umgebung, in die eine Lösung zur Lebenszyklusverwaltung des Benutzers im Verbund eingebunden werden soll, vorteilhaft ein. Die Unterstützung für Anwendungen zur Lebenszyklusverwaltung des Benutzers im Verbund kann als J2EE/C#-Anwendung auf der Grundlage der vorhandenen Umgebung realisiert werden. Die Anwendung zur Lebenszyklusverwaltung des Benutzers im Verbund wird von einer Kontakteinheit als Reaktion auf eine Anforderung von einem Endbenutzer aufgerufen. Diese Anforderung kann so einfach wie eine Anforderung für eine geschützte Ressource von einem Benutzer sein, dessen Identität noch nicht festgestellt wurde, wie vorstehend mit Bezug auf 5 erörtert wurde. Die Anwendungen zur Lebenszyklusverwaltung des Benutzers im Verbund sind unabhängig, da sie keine Interaktion mit anderen Teilen der Datenverarbeitungsumgebung erforderlich machen; sobald das benötigte Protokoll erfolgreich ausgeführt worden ist, wird die Steuerung an die Kontakteinheit zurückgegeben, an der die Anforderung des Benutzers ursprünglich empfangen wurde. Folglich sind in einer vorhandenen Umgebung nur geringfügige Änderungen notwendig, um diese Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund unterstützen zu können. Wenn es sich bei der Funktion zur Lebenszyklusverwaltung des Benutzers im Verbund, die aufgerufen werden muss, beispielsweise um eine Anforderung für eine Einmalanmeldung handelt, kann dies als Reaktion auf eine Anforderung für eine geschützte Ressource von einem Benutzer, dessen Identität noch nicht festgestellt wurde, stattfinden, wobei anstelle des normalen Identitätsprüfungsprozesses die Einmalanmeldeoperation der Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund aufgerufen wird. Bei der vorliegenden Erfindung ist dazu vorzugsweise eine einfache Konfigurationsänderung erforderlich, die es ermöglicht, dass der Benutzer statt zu einem älteren Anmeldeprozess zu der Anwendung zur Lebenszyklusverwaltung des Benutzers im Verbund umgeleitet wird.
Unterstützung der Vertrauensinfrastruktur zur Lebenszyklusverwaltung des Benutzers im Verbund
Wie vorstehend erwähnt wurde, sind diese Lösungen nach dem Stand der Technik jedoch nicht skalierbar, um die Voraussetzungen für eine lose verbundene Umgebung zu schaffen, in der neue Partner ganz einfach in den Rechnerdialog aufgenommen oder alte Partner aus der Datenverarbeitungsumgebung entfernt werden können, ohne auf beiden Seiten Änderungen an der Umgebung vornehmen zu müssen. Das Merkmal der losen Verbundenheit, das eine Lösung für die Lebenszyklusverwaltung des Benutzers im Verbund möglich macht, bezieht sich auf die Übereinstimmung zwischen Verbundpartnern und die Möglichkeit eines Endbenutzers, auf kontrollierte Ressourcen in den Datenverarbeitungsumgebungen dieser Partnerumgebungen zuzugreifen. Dieses Merkmal der losen Verbundenheit gilt nicht allgemein für die Vertrauensbeziehungen zwischen Verbundpartnern oder Verbundparteien. Es gibt folglich einen Kompromiss; das Merkmal der losen Verbundenheit wird erzielt, indem man das Merkmal einer engen Verbundenheit zwischen den Verbundpartnern oder Verbundunternehmen in Bezug auf ihre Vertrauensbeziehungen aufrechterhält. Diese eng verbundenen Vertrauensbeziehungen legen die Funktionalität fest, die einem Endbenutzer in einer Verbundumgebung zur Verfügung steht, und sie legen auch die Datenverarbeitungsmechanismen fest, die verwendet werden, um Datenübertragungen in dieser Verbundumgebung vertrauen zu können und sie sicher zu machen.
Die vorliegende Erfindung erkennt gemäß einer Ausführungsform, dass sich das Merkmal der engen Verbundenheit einer Vertrauensbeziehung zwischen zwei Partnern/Parteien mittels vertrauensbezogener oder sicherheitsbezogener Daten darstellen lässt. Genauer gesagt, die vorliegende Erfindung führt vorzugsweise einen Vertrauensdienst aus, der Funktionen zur Verwaltung von kryptografischen Schlüsseln und Sicherheits-Token sowie zur Umsetzung der Identität beinhaltet, die eine Vertrauensbeziehung definieren.
Es sei erwähnt, dass es zwischen der Art des kryptografischen Vertrauens, von dem eine Ausführungsform der vorliegenden Erfindung Gebrauch macht, und dem Vertrauen auf der Transportebene mit SSL-Zertifikaten einen Unterschied gibt; wenn auf der Protokoll-/Anwendungsebene eine Vertrauensbeziehung gestaltet wird, muss eine zusätzliche "Bindung" der Identität, die in einem Zertifikat vorgegeben wird, an die Identität, mit der eine geschäftliche/rechtliche Vereinbarung getroffen wurde, erfolgen. Es ist folglich nicht ausreichend, einfach vorhandene Vertrauensbeziehungen auf SSL-/Transportebene wirksam zu nutzen, da sie nicht in ausreichendem Maße über die zusätzlichen Bindungen verfügen, die für diese Art von Funktionalität notwendig sind.
Die Kombination aus Schlüsseln, Token und Identitätsumsetzungen wurde gewählt, um aus folgenden Gründen eine Vertrauensbeziehung darzustellen. In einer bestimmten Vertrauensbeziehung werden Nachrichten zwischen Partnern mit einem Satz von kryptografischen Schlüsseln signiert und verschlüsselt. Die Schlüssel, die bei Transaktionen zwischen den Partnern verwendet werden sollen, werden den Partnern normalerweise vor einer jeden Transaktion zur Kenntnis gebracht, wodurch ein Partner Nachrichten signieren/verschlüsseln und der andere Partner diese Nachrichten auf Gültigkeit prüfen/entschlüsseln kann. Überdies ist eines der Elemente einer Nachricht, die signiert/verschlüsselt werden kann, das Sicherheits-Token, das zur Bestätigung der Identität oder der Rolle des Endbenutzers verwendet wird. Die Struktur dieses Sicherheits-Token wird ebenfalls vor jeder Transaktion zwischen den Partnern festgelegt, so dass gewährleistet ist, dass beide Parteien den Inhalt des Sicherheits-Token verstehen; diese Gewährleistung kann das Ergebnis einer an eine dritte Partei in Form eines vertrauenswürdigen Vermittlers gerichtete Hilfeanforderung sein, der als Vermittler zwischen den Parteien auftreten kann. Darüber hinaus gibt es in dem Sicherheits-Token eine vorgegebene Identität, einen Satz Rollen und/oder einen Satz von Attributen, die aus einem von einem Identitätsanbieter bestätigten Datenformat in ein Datenformat umgesetzt werden können, das von einem Diensteanbieter verwendet wird; diese Umsetzung wird auf der Grundlage einer Identitätsumsetzung vorgenommen, die wiederum zuvor gemäß vereinbarten Attributen festgelegt wurde, welche in dem Sicherheits-Token geltend gemacht werden.
Die vorliegende Erfindung sorgt folglich für Unterstützung zur Darstellung der Eigenschaften einer engen Kopplung einer vertrauenswürdigen Beziehung zwischen zwei Partnern als ein Tupel von sicherheitsbezogenen Daten, insbesondere ein Satz von Datenelementen, die {kryptografische Schlüssel, Sicherheits-Token und Identitätsumsetzungen} umfassen; anders ausgedrückt, in einer Ausführungsart der vorliegenden Erfindung stellt diese Tupel eine Vertrauensbeziehung dar. Gemäß einer Ausführungsform betrifft die vorliegende Erfindung Verfahren und Systeme, die es ermöglichen, eine Vertrauensbeziehung (und die Verwaltung dieser Vertrauensbeziehung) und die Funktionalität, die notwendig ist, um eine Lösung in Form der Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund anzubieten, voneinander zu trennen. Genauer gesagt, die Festlegung einer Vertrauensbeziehung in der Weise, dass sie ein Tupel mit kryptografischen Schlüsseln, Sicherheits-Token und Identitätsumsetzungen umfasst, und die anschließende Bindung eines bestimmten Tupels an eine Gruppe von mindestens zwei Verbundpartnern in einer Weise, die unabhängig von der Festlegung der Funktionalität ist, die diesen Verbundpartnern zur Verfügung steht, bietet einen skalierbaren Ansatz für die Verbundverwaltung, wie nachstehend ausführlicher erklärt wird.
Nun Bezug nehmend auf 7 zeigt ein Blockschaubild einen Aufbau von logischen Komponenten, der die Verwaltung einer Vertrauensbeziehung von der Verwaltung des Lebenszyklus des Benutzers im Verbund trennt. Die Anwendung 702 zur Lebenszyklusverwaltung des Benutzers im Verbund ist ähnlich der in 5 gezeigten Anwendung 508 zur Lebenszyklusverwaltung des Benutzers im Verbund. Die Anwendung 702 zur Lebenszyklusverwaltung des Benutzers im Verbund unterstützt die Einmalanmeldung, die Einmalabmeldung, die Kontenverknüpfung/Aufhebung der Verknüpfung und/oder andere zusätzliche Verbundfunktionen, die ausgeführt werden können, wie zum Beispiel die Ermittlung des Identitätsanbieters. Alle diese Funktionen nutzen in einer bestimmten Weise vorteilhaft eine Vertrauensbeziehung zwischen Partnern. Wenn die Anwendung 702 zur Lebenszyklusverwaltung des Benutzers im Verbund beispielsweise ein Sicherheits-Token benötigt, um auf eine(n) Endbenutzer/Anwendung in einer Verbundumgebung zu verweisen, werden diese Daten von einem vertrauenswürdigen Dienst 704 durch an ihn gerichtete Aufrufe/Nachrichten 706 angefordert; verschiedene Arten von Schnittstellen zwischen der Anwendung zur Lebenszyklusverwaltung des Benutzers im Verbund und dem vertrauenswürdigen Dienst können realisiert werden. Darüber hinaus kann der vertrauenswürdige Dienst mit anderen Komponenten in einer Verbunddomäne, einschließlich eines Kontaktsservers, verbunden werden. Die Funktionalität zur Verwaltung von Vertrauensbeziehungen 708 stellt lediglich eine logische Grenze dar, die die Funktionsmodule abgrenzt, welche an der Unterstützung der Verwaltung von Vertrauensbeziehungen für einen bestimmten Verbundpartner beteiligt sind.
Der vertrauenswürdige Dienst 704 ist eine beispielhafte Ausführungsform eines vertrauenswürdigen Proxy/Dienstes, der ähnlich dem vorstehend erörterten vertrauenswürdigen Proxy/Dienst wie zum Beispiel dem vertrauenswürdigen Proxy/Dienst 244 ist, der in 2B gezeigt ist, oder dem vertrauenswürdigen Proxy/Dienst 254, der in 2C gezeigt ist. Der vertrauenswürdige Dienst 704 stellt jedoch eine Ausführungsform der vorliegenden Erfindung dar, bei der der vertrauenswürdige Proxy/Dienst so erweitert wurde, dass er Funktionen enthält, um Vertrauensbeziehungen in einer bestimmten Weise zu verwalten. Die Verwaltung von Vertrauensbeziehungen einer Ausführungsform der vorliegenden Erfindung umfasst Funktionen zur Verwaltung von kryptografischen Schlüsseln, zur Verwaltung von Sicherheits-Token und zur Verwaltung der Umsetzung von Identitäten. Somit ist der vertrauenswürdige Dienst 704 für die Erzeugung der entsprechenden Sicherheits-Token einschließlich der Signierung/Verschlüsselung, die an diesen Token vorgenommen werden muss, und für die entsprechende Feststellung des Endbenutzers/der Anwendung, in dessen beziehungsweise deren Namen eine Verbundanforderung gestellt wird, verantwortlich.
Der vertrauenswürdige Dienst 704 kann als ein Dienst betrachtet werden, der den Zugriff auf verschiedene unabhängige sicherheitsbezogene oder vertrauensbezogene Dienste vermittelt. Diese unabhängigen Dienste, zu denen auch der vertrauenswürdige Dienst gehört, können auf einer gemeinsamen Einheit oder einem gemeinsamen Server oder in einer gemeinsamen Anwendung ausgeführt werden; alternativ dazu wird jeder Dienst als eine unabhängige Server-Anwendung ausgeführt. Der Schlüsselverwaltungsdienst 710 verwaltet die kryptografischen Schlüssel und/oder digitalen Zertifikate, die zur Übertragung von Daten im Kontext einer Vertrauensbeziehung erforderlich sind. Der Sicherheitstoken-Dienst 712 ist für die Verwaltung von unabhängigen Token-Instanzen verantwortlich, die für sichere Übertragungen oder in sicherheitsrelevanten Übertragungen zwischen Partnern verwendet werden; die Sicherheitstoken-Einschübe 714 stellen die Funktionen für verschiedene Arten von unabhängig veröffentlichten oder entwickelten Standards oder Spezifikationen für Sicherheits-Token bereit. Der Identitätsdienst 716 (oder der Identitäts-/Attributdienst 716) ist für die Verwaltung der Identitäten und/oder Attribute zuständig, die in den Sicherheitstoken enthalten sind, einschließlich der Lokalisierungsattribute, die einem Token hinzugefügt werden müssen, und der Lokalisierungsattribute, die einer lokalen Antwort an den Kontaktserver am Diensteanbieter auf der Grundlage eines Token hinzugefügt werden müssen, das von einem Identitätsanbieter empfangen wurde.
Eine Trennung der Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund von der Funktionalität zur Verwaltung der Vertrauensbeziehung bedeutet, dass die Verwaltung der beiden verschiedenen Funktionsarten ebenfalls getrennt werden kann. Dies bedeutet, dass in dem Fall, in dem sich Daten über eine Vertrauensbeziehung ändern sollten, z. B. wenn kryptografische Schlüssel aus Sicherheitsgründen ersetzt werden, sich die erforderliche Änderung nicht auf die Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund auswirkt. Überdies kann dieselbe Funktionalität verschiedenen Partnern zur Verfügung gestellt werden, da die Verwaltung der Vertrauensbeziehung dieser Partner nicht an die Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund gebunden ist. Darüber hinaus bedeutet eine Trennung der Verwaltung der Vertrauensbeziehung, dass eine Vertrauensbeziehung aufrechterhalten werden kann, wenn eine bestehende Vertrauensbeziehung um neue Funktionen erweitert wird, z. B., wenn eine bestimmte Beziehung, die zuvor nur Einmalanmeldeoperationen unterstützt hat, um Unterstützung für Einmalabmeldeoperationen erweitert wird. Schließlich bedeutet die Trennung der Vertrauensverwaltung, dass eine Vertrauensbeziehung und ihre Verwaltung in anderen Kontexten wiederverwendet werden kann, wie zum Beispiel bei der Verwaltung der Sicherheit von Webdiensten oder bei auf Webdienste ausgerichteten Architekturen; folglich ist die vorliegende Erfindung vorzugsweise nicht auf eine passive Client-Architektur, die auf einem Browser beruht, beschränkt.
Herstellen von Verbundbeziehungen durch importierte Konfigurationsdateien
Die nachfolgende Beschreibung der 8A bis 8D dient zur Zusammenfassung von einigen der zugehörigen Konzepte, um einen Kontext für die Erklärung des Konzepts einer Vertrauensbeziehung und der anschließenden Erklärung einer Ausführungsform der vorliegenden Erfindung vorzusehen, in dem die zuvor beschriebenen Merkmale die Herstellung einer Vertrauensbeziehung zwischen Geschäftspartnern unter Nutzung des elektronischen Datenaustauschs vereinfachen. Die 8A bis 8D sind Blockschaubilder, die die Aufteilung der bereitgestellten Funktionalität hervorheben. Genauer gesagt, die 8A bis 8D zeigen Ausführungsformen der vorliegenden Erfindung, in denen verschiedene Sätze von Funktionen aufgeteilt werden, um bei der Realisierung von Datenverarbeitungs-Verbundumgebungen, die gleichzeitig mehrere Verbundspezifikationen erfüllen können, während an bereits bestehenden Datenverarbeitungsumgebungen nur geringfügige Änderungen vorgenommen werden müssen, um eine Anbindung an die Verbundfunktionalität herzustellen, einen hohen Wirkungsgrad zu erzielen. Die Beschreibung der 8A bis 8D bezieht sich auf ähnliche Elemente mit gleichen Bezugszahlen.
Nun Bezug nehmend auf 8A zeigt ein Blockschaubild eine hohe Abstraktionsebene der logischen Funktionalität einer Datenverarbeitungs-Verbundumgebung. Wie vorstehend kurz erwähnt wurde, müssen ein Unternehmen und seine möglichen Verbundpartner eine gewisse Vorarbeit leisten, bevor sie an einer Datenverarbeitungs-Verbundumgebung teilnehmen können. Ein Vorteil der Verbundarchitektur besteht darin, dass bei einer bestimmten Unternehmensdomäne 800 nur geringfügige, die Infrastruktur betreffende Änderungen 802 an der Funktionalität 804 einer bereits bestehenden Datenverarbeitungsumgebung eines Unternehmens und seiner Verbundpartner vorgenommen werden müssen, um eine Anbindung an die Infrastruktur-Funktionalität des Verbunds herzustellen. Diese Merkmale wurden vorstehend mit Bezug auf 2B ausführlicher beschrieben.
Nun Bezug nehmend auf 8B zeigt ein Blockschaubild eine hohe Abstraktionsebene der logischen Funktionalität einer Datenverarbeitungs-Verbundumgebung, die die Art und Weise veranschaulicht, in der die Trennung der Verbundfunktionalität und der Kontaktstellen-Funktionalität von der Funktionalität zur Verwaltung von Vertrauensbeziehungen vorgesehen ist. Wie vorstehend erklärt wurde, wird innerhalb der Infrastruktur-Funktionalität 806 des Verbunds eine Kombination aus der Kontaktstellen-Funktionalität und der Verbund-Betriebsfunktionalität 808 von der Funktionalität 810 zur Verwaltung von Vertrauensbeziehungen getrennt, wodurch Benutzer in einem Verbund durch bereits vorhandene Anwendungsserver 814 über eine Verbundfunktionalität gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung auf geschützte Ressourcen 812 zugreifen können. Diese Trennung der Kontaktstellen-Funktionalität von der Funktionalität zur Verwaltung von Vertrauensbeziehungen und die sich daraus ergebenden Vorteile wurden vorstehend in Bezug auf Komponenten der Verbundinfrastruktur, die in 2C und 4 gezeigt sind, und in Bezug auf Funktionsprozesse, die in den 3A bis 3E gezeigt sind, ausführlich beschrieben.
Es sei jedoch erwähnt, dass der Kontaktserver bei der Erklärung der Verbundfunktionalität in den ersten Figuren, d. h. in den Figuren bis 4, als ein Server beschrieben wird, der Kontaktoperationen zusammen mit Verbundfunktionen und Verbundoperationen durchführt, z. B. die Abwicklung der Verarbeitung von Sicherheitsbestätigungen und Sicherheitstoken mit Hilfe eines vertrauenswürdigen Proxy/Dienstes, insbesondere in Bezug auf Einmalanmeldeoperationen, d. h. Identitätsprüfungsoperationen im Verbund, vornimmt, ohne näher zwischen den vielen Arten der Verbundfunktionen und Verbundoperationen, die zwischen Verbundpartnern ausgeführt werden könnten, zu unterscheiden. Anders ausgedrückt, bei der Erklärung der Verbundfunktionalität in den ersten Figuren wird nicht zwischen der Funktionalität der Kontaktstelle und der Betriebsfunktionalität des Verbunds unterschieden; der Kontaktserver wird als ein Server beschrieben, der kombinierte Funktionen ausführt, wobei ein Teil der Verantwortlichkeiten eines Kontaktservers darin besteht, für eine Domäne eines Verbundunternehmens die Funktion einer Kontakteinheit zu übernehmen, und der andere Teil der Verantwortlichkeiten des Kontaktservers darin besteht, alle Verbundoperationen und Verbundfunktionen auszuführen, während er sich darauf verlässt, dass der vertrauenswürdige Proxy/Dienst diejenigen Operationen ausführt, die die Vertrauensstellung/die Sicherheit betreffen. In der Beschreibung im Anschluss an 4 folgen jedoch weitere Einzelheiten über die Art und Weise, in der Ausführungsformen der vorliegenden Erfindung eine Unterscheidung zwischen der Funktionalität der Kontaktstelle und der anderen Betriebsfunktionalität des Verbunds vornehmen können, wie mit Bezug auf 8C dargelegt wird.
Nun Bezug nehmend auf 8C zeigt ein Blockschaubild eine hohe Abstraktionsebene der logischen Funktionalität einer Datenverarbeitungs-Verbundumgebung, die die Art und Weise veranschaulicht, in der die weitere Trennung der Verbund-Betriebsfunktionalität von der Kontaktstellen-Funktionalität vorgesehen ist. Wie vorstehend erklärt wurde, wird die Funktionalität zur Verwaltung von Vertrauensbeziehungen 810 im Rahmen der Infrastruktur-Funktionalität des Verbunds 806 von anderen Funktionen getrennt, die in der Infrastruktur des Verbunds bereitgestellt werden; überdies können weitere Unterscheidungen zwischen diesen anderen Funktionen so vorgenommen werden, dass die Funktionalität der Kontaktstelle 816 als eine von der Betriebsfunktionalität des Verbunds 818 getrennte Funktionalität dargestellt werden kann. Diese Trennung der Funktionalität der Kontaktstelle von der Betriebsfunktionalität des Verbunds und die sich daraus ergebenden Vorteile wurden vorstehend in Bezug auf Komponenten der Verbundinfrastruktur, die in 5 gezeigt sind, und mit Bezug auf Funktionsprozesse, die in 6 gezeigt sind, ausführlicher beschrieben, wobei die Anwendung 508 zur Lebenszyklusverwaltung des Benutzers im Verbund in 5 (in 6 auch als FULM-Anwendung bezeichnet) einen Aspekt der Betriebsfunktionalität des Verbunds darstellt.
Folglich vereinfacht die vorliegende Erfindung vorzugsweise die Aufteilung beziehungsweise den modularen Aufbau von verschiedenen Funktionalitäten. In einer Ausführungsform der vorliegenden Erfindung wird eine Kombination aus der Funktionalität der Kontaktstelle und der Betriebsfunktionalität des Verbunds von der Funktionalität zur Verwaltung von Vertrauensbeziehungen getrennt. In einer weiteren Ausführungsform der vorliegenden Erfindung wird neben der fortgesetzten Aufteilung der Funktionalität zur Verwaltung von Vertrauensbeziehungen die Funktionalität der Kontaktstelle von der Betriebsfunktionalität des Verbunds getrennt, wobei ein Aspekt davon die Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund darstellt. Weitere Unterschiede bezüglich der Trennung der Funktionalität zur Verwaltung von Vertrauensbeziehungen und der Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund sind vorstehend mit Bezug auf 7 beschrieben. Unter Berücksichtigung dieser Aufteilungen zeigt 8D noch eine weitere Ausführungsform der vorliegenden Erfindung, in der weitere Unterschiede veranschaulicht sind.
Nun Bezug nehmend auf 8D zeigt ein Blockschaubild eine hohe Abstraktionsebene der logischen Funktionalität einer Datenverarbeitungs-Verbundumgebung, die die Art und Weise veranschaulicht, in der die weitere Trennung der Verbundfunktionalität in die Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund und der Funktionalität zur Verwaltung von Vertrauensbeziehungen vorgesehen ist. Wie vorstehend mit Bezug auf 8C erwähnt wurde, kann die Funktionalität der Kontaktstelle 816 als eine von der Betriebsfunktionalität des Verbunds getrennte Funktionalität 818 dargestellt werden. Wie mit Bezug auf 5 und 6 erklärt wurde, kann eine Kontakteinheit unabhängig von der Betriebsfunktionalität des Verbunds in einer Domäne arbeiten, wobei nur geringfügige Änderungen an der Konfiguration notwendig sind, um eintreffende Anforderungen für Verbundoperationen im Vergleich zu Anforderungen für den Zugriff auf geschützte Ressourcen zu erkennen. Diese Fähigkeit spiegelt sich folglich in 8D wider, indem die Funktionalität der Kontaktstelle 820 als eine von der Infrastruktur-Funktionalität des Verbunds 806 getrennte Funktionalität gezeigt ist.
Wie vorstehend mit Bezug auf 8B erwähnt wurde, kann in einer Ausführungsform der vorliegenden Erfindung eine Kombination aus der Funktionalität der Kontaktstelle 820 und der Betriebsfunktionalität des Verbunds 808 von der Funktionalität zur Verwaltung von Vertrauensbeziehungen 810 im Rahmen der Infrastruktur-Funktionalität des Verbunds 806 getrennt werden. Nachdem die Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund vorstehend mit Bezug auf 5 und 6 beschrieben wurde, wurde mit der Beschreibung von 7 die Art und Weise erklärt, in der die Funktionalität zur Verwaltung von Vertrauensbeziehungen weiterhin getrennt von der Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund realisiert werden kann. Zudem wurde in der Beschreibung von 7 darauf hingewiesen, dass dieselbe Funktionalität verschiedenen Verbundpartnern modular zur Verfügung gestellt werden kann.
Anders ausgedrückt, die Funktionalität zur Verwaltung von Vertrauensbeziehungen kann so realisiert werden, dass sie über eine Schnittstelle an die Infrastruktur-Funktionalität des Verbunds angebunden werden kann, aber dennoch unabhängig von dieser Funktionalität ist. Diese Fähigkeit spiegelt sich folglich in 8D wider, indem die Funktionalität zur Verwaltung von Vertrauensbeziehungen 822 als eine von der Infrastruktur-Funktionalität des Verbunds 806 getrennte Funktionalität gezeigt ist. Die Bedeutung dieses Unterschieds wird nachstehend ausführlicher aufgezeigt.
8D zeigt auch weitere Unterschiede in der Betriebsfunktionalität des Verbunds einer Ausführungsform der vorliegenden Erfindung. Die Betriebsfunktionalität des Verbunds wie zum Beispiel die Betriebsfunktionalität des Verbunds 818 umfasst diejenigen Operationen beziehungsweise Funktionen, die Transaktionen oder Interaktionen zwischen Verbundpartnern in einer Datenverarbeitungs-Verbundumgebung möglich machen. Die Betriebsfunktionalität des Verbunds kann dann der Infrastruktur-Funktionalität des Verbunds, beispielsweise der Infrastruktur-Funktionalität des Verbunds 806, gegenübergestellt werden, die diejenigen Operationen beziehungsweise Funktionen umfasst, die es einem Verbundpartner ermöglichen, die Betriebsfunktionalität des Verbunds in Verbindung mit der bereits vorhandenen Unternehmens-Funktionalität zu realisieren.
Vorstehend wurde erwähnt, dass die Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund, wie sie beispielsweise durch die Anwendung 508 in 5 und durch die FULM-Anwendung in 6 dargestellt ist, lediglich ein Aspekt der Betriebsfunktionalität des Verbunds ist. Wir vorstehend erläutert wurde, umfasst die Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund Funktionen zur Unterstützung oder Verwaltung von Verbundoperationen in Bezug auf die jeweiligen Benutzerkonten oder Benutzerprofile eines bestimmten Benutzers in mehreren Verbunddomänen; in manchen Fällen sind die Funktionen oder die Operationen auf eine bestimmte Verbundsitzung für den Benutzer beschränkt. Anders ausgedrückt, die Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund bezieht sich auf die Funktionen, die die Verwaltung von Verbundoperationen über eine Vielzahl von Verbundpartnern hinweg, unter Umständen nur während des Lebenszyklus einer einzigen Benutzersitzung, in einer Datenverarbeitungs-Verbundumgebung ermöglichen.
In 8D ist zu sehen, dass die Betriebsfunktionalität des Verbunds mehrere Aspekte umfassen kann. Zusammen mit der Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund 824 als ein Aspekt der Betriebsfunktionalität des Verbunds kann eine Ausführungsform der vorliegenden Erfindung auch die Funktionalität der Verbundbeziehung 826, die nachstehend ausführlicher gezeigt wird, realisieren; der Unterschied zwischen einer Vertrauensbeziehung zwischen Verbundpartnern und einer Verbundbeziehung zwischen Verbundpartnern wird nachstehend ebenfalls ausführlicher erklärt.
Nun Bezug nehmend auf die 9A bis 9B zeigen Venn-Diagramme die jeweilige Art und Weise, in der eine Verbundbeziehung eine Vertrauensbeziehung in Verbindung mit einer Auswahl an Verbundfunktionen beinhaltet. Ein Verbund legt vorzugsweise Geschäftsprozesse zwischen Geschäftspartnern offen. Die Offenlegung der Geschäftsprozesse eines Unternehmens erfolgt nicht ohne Berücksichtigung vieler Faktoren; so würde ein Unternehmen beispielsweise die Offenlegung von Geschäftsprozessen nur gegenüber vertrauenswürdigen Partnern in Erwägung ziehen. Die vorliegende Erfindung erkennt folglich die Notwendigkeit, dass es einem Unternehmen ermöglicht werden muss, die Offenlegung seiner Geschäftsprozesse nur auf vertrauenswürdige Verbundpartner zu beschränken, insbesondere in Anbetracht der Tatsache, dass verschiedene Geschäftspartner auch untereinander auf unterschiedlichen Vertrauensebenen kommunizieren.
Jedoch würden selbst in derselben Datenverarbeitungs-Verbundumgebung verschiedene Gruppen von Verbundpartnern unterschiedliche Anforderungen an die Interaktion untereinander stellen. Vorzugsweise erkennt die vorliegende Erfindung folglich die Notwendigkeit, dass es einem Unternehmen ermöglicht werden muss, die Offenlegung seiner Geschäftsprozesse gegenüber verschiedenen Geschäftspartnern auf unterschiedliche Weise zu beschränken.
Bei der vorliegenden Erfindung umfasst die Verbundfunktionalität vorzugsweise elektronische Operationen beziehungsweise Funktionen, die elektronische Transaktionen zwischen vertrauenswürdigen Verbundpartnern unterstützen. Da zwischen Verbundpartnern vor der Offenlegung von Geschäftsprozessen eine bestimmte Vertrauensebene vorhanden sein muss, sollte zwischen diesen Verbundpartnern eine Vertrauensbeziehung bereits vorhanden ein, bevor eine Verbundbeziehung hinzukommt. Anders ausgedrückt, die Verbundfunktionalität umfasst eine Auswahl an elektronischen Transaktionen, die anschließend einer Vertrauensbeziehung zugeordnet werden. Diese Logik zeigt sich in den Venn-Diagrammen der 9A bis 9B.
Nun Bezug nehmend auf 9A zeigt eine schematische Darstellung, dass die Verbundbeziehung 902 zwischen zwei Verbundpartnern eine Verbindung zwischen der Vertrauensbeziehung 904 dieser beiden Verbundpartner und einer Auswahl eines Satzes von Verbundoperationen/-funktionen 906 beinhaltet, die von diesen beiden Verbundpartnern ausgeführt werden sollen. Wenn die schematische Darstellung von 9A mit der Art und Weise verglichen wird, in der eine Ausführungsform der vorliegenden Erfindung die Funktionalität zur Verwaltung einer Vertrauensbeziehung und die Infrastruktur-Funktionalität eines Verbunds in der Datenverarbeitungsumgebung eines Unternehmens einrichten kann, werden die Vorteile der Realisierung einer Datenverarbeitungs-Verbundumgebung sichtbar, wie nachstehend ausführlicher dargelegt wird.
Nun Bezug nehmend auf 9B zeigt eine schematische Darstellung, dass zwei Verbundpartner mehrere Verbundbeziehungen untereinander haben können. Die erste Verbundbeziehung 912 zwischen zwei Verbundpartnern beinhaltet eine Verbindung zwischen der ersten Vertrauensbeziehung 914 dieser beiden Verbundpartner und einer ersten Auswahl eines Satzes von Verbundoperationen/-funktionen 916, die von diesen beiden Verbundpartnern ausgeführt werden sollen. Ferner beinhaltet die zweite Verbundbeziehung 922 zwischen zwei Verbundpartnern eine Verbindung zwischen der zweiten Vertrauensbeziehung 924 dieser beiden Verbundpartner und einer zweiten Auswahl eines Satzes von Verbundoperationen/-funktionen 926, die von diesen beiden Verbundpartnern ausgeführt werden sollen. In dieser Ausführungsform werden mehrere Vertrauensbeziehungen zwischen den beiden Verbundpartnern in ihren diversen Verbundbeziehungen verwendet. Die diversen Vertrauensbeziehungen können ähnliche Eigenschaften, aber unterschiedliche Ausführungsdaten haben, beispielsweise verschiedene kryptografische Schlüssel ähnlicher Größe oder nur unterschiedliche digitale Zertifikate, wodurch beispielsweise verschiedene Verbundoperationen mit verschiedenen digitalen Zertifikaten durchgeführt werden können.
Die beiden verschiedenen Auswahlgruppen an Funktionen 916 und 926 können jedoch Vertrauensbeziehungen mit unterschiedlichen Eigenschaften nutzen, was bedeutet, dass verschiedene Verbundoperationen in Bezug auf Vertrauensbeziehungen unterschiedlicher Stärke durchgeführt werden können. Unterschiedliche Stärkegrade von Vertrauensbeziehungen können auf verschiedenen Kriterien beruhen, z. B. verschiedenen kryptografischen Algorithmen oder einer unterschiedlichen Größe der kryptografischen Schlüssel. Einmalanmeldeoperationen können beispielsweise unter Nutzung einer schwächeren Vertrauensbeziehung durchgeführt werden, während andere Verbundoperationen, wie zum Beispiel Versorgungsprozesse von Benutzern, um sie mit den grundsätzlichen Voraussetzungen für ihre Tätigkeit auszustatten, unter Nutzung einer stärkeren Vertrauensbeziehung durchgeführt werden.
Beispielsweise treten zwei als Paar zugeordnete Verbundpartner in Dialogverkehr, um ein erstes Handelsprojekt zu unterstützen, möglicherweise mit vielen anderen Verbundpartnern gemeinsam, und das Handelsprojekt kann aufgrund verschiedener ausgehandelter Geschäftsvereinbarungen die Nutzung einer ersten Vertrauensbeziehung mit bestimmten Eigenschaften erforderlich machen. Gleichzeitig können diese Verbundpartner in Dialogverkehr treten, um ein zweites Handelsprojekt zu unterstützen, möglicherweise mit einer anderen Gruppe von Verbundpartnern, und dieses Handelsprojekt kann die Nutzung einer zweiten Vertrauensbeziehung mit Eigenschaften erforderlich machen, die von den Eigenschaften der ersten Vertrauensbeziehung abweichen, wobei dies alles anderen Geschäftsvereinbarungen unterliegt. In diesem Szenario würden die verschiedenen Handelsprojekte folglich unterschiedliche Verbundbeziehungen voraussetzen, die auch unterschiedliche Vertrauensbeziehungen umfassen.
Nun Bezug nehmend auf 10 zeigt ein Datenflussdiagramm mehrere Operationen, die von zwei als Paar zugeordneten Geschäftspartnern durchgeführt werden, um in einer Datenverarbeitungs-Verbundumgebung gemäß einer Ausführungsform der vorliegenden Erfindung interaktiv miteinander zu kommunizieren. Ein Unternehmen, z. B. der Partner 1002, und sein möglicher Verbundpartner, z. B. der Partner 1004, müssen eine Verbundbeziehung herstellen, bevor sie versuchen, in einer Datenverarbeitungs-Verbundumgebung in Dialogverkehr zu treten. Wie vorstehend erwähnt wurde, beruht eine Verbundbeziehung auf einer Vertrauensbeziehung; diese Vertrauensbeziehung stellt das Vertrauen eines Verbundpartners in die geschäftlichen und rechtlichen Vereinbarungen der Partner dar, wobei den Partnern die Möglichkeit gegeben wird, Aspekte ihrer Interaktion festzulegen, z. B., welche Art von Leistungspflicht mit einer bestimmten Handlung verbunden ist, vorausgesetzt, diese Handlung wurde im Rahmen einer bestimmten Vertrauensbeziehung durchgeführt, die es den Partnern wiederum gestattet, Richtlinien, die zulässige Handlungen bestimmen, auf die Art der Vertrauensbeziehung anzuwenden, unter der sie angefordert werden. Folglich müssen ein Unternehmen und seine möglichen Verbundpartner eine Vertrauensbeziehung herstellen, bevor sie versuchen, in einem Verbund interaktiv zu kommunizieren, wie durch den interaktiven Datenfluss 1006 gezeigt ist. Unter der Annahme, dass eine Verbundbeziehung einer Vertrauensbeziehung eine Auswahl an Verbundfunktionen zuordnet, müssen die Verbundfunktionen an jedem Partner konfiguriert werden, was als die Konfigurationsoperationen 1008 und 1010 gezeigt ist, woraufhin eine Verbundbeziehung aufgebaut werden kann, wie durch den interaktiven Datenfluss 1012 dargestellt ist. Nachdem die Verbundbeziehung hergestellt worden ist, können die Geschäftspartner im Verbund interaktiv miteinander kommunizieren, indem sie an einer Verbundtransaktion teilnehmen, wie durch den interaktiven Datenfluss 1014 gezeigt ist.
Wenn man weiter annimmt, dass ein Unternehmen die geeignete Unterstützung haben möchte, um Verbundtransaktionen erfolgreich durchzuführen, so sei jedoch darauf hingewiesen, dass die Verbundfunktionen konfiguriert werden müssen, bevor eine Verbundtransaktion eingeleitet wird. Die Verbundfunktionen können beispielsweise konfiguriert werden, bevor eine Vertrauensbeziehung hergestellt wird. Zwar lassen sich Verbundfunktionen zum Zeitpunkt der Konfiguration einer Verbundbeziehung möglicherweise leichter auswählen, doch kann die Konfiguration der Verbundfunktionen auch stattfinden, nachdem eine Verbundbeziehung hergestellt worden ist. überdies können die Verbundfunktionen geändert werden, nachdem eine Verbundbeziehung hergestellt worden ist, insbesondere wenn es darum geht, die Verbundfunktionalität zu verbessern, ohne dass dies unbedingt eine Änderung an einer zuvor hergestellten Verbundbeziehung erforderlich macht.
Nun Bezug nehmend auf 11 zeigt ein Blockschaubild eine Interaktion zwischen Geschäftspartnern gemäß einer Ausführungsform der vorliegenden Erfindung, um in Vorbereitung der Herstellung einer Verbundbeziehung zunächst eine Vertrauensbeziehung aufzubauen. Wie weiter oben angemerkt wurde, schließen Vertrauensbeziehungen eine Art von Bootstrapping-Prozess ein, durch den ein Anfangsvertrauen zwischen Geschäftspartnern aufgebaut wird. Ein Teil dieses Bootstrapping-Prozesses kann die Festlegung von gemeinsamen geheimen Schlüsseln und Regeln sein, die die erwarteten und/oder zulässigen Arten von Token und Kennungsumsetzungen angeben. Dieser Bootstrapping-Prozess kann bandextern erfolgen, da er auch die Festlegung von Geschäftsvereinbarungen beinhalten kann, die die Teilnahme eines Unternehmens an einem Verbund und die mit dieser Teilnahme verbundenen Pflichten regeln.
Der Bootstrapping-Prozess hat den Zweck, eine Bindung eines Geschäftspartners, d. h. eines Unternehmens, an die vertrauenswürdigen Daten des Geschäftspartners vorzunehmen; dazu gehört ferner die Bindung einer Identität an kryptografische Schlüssel als Teil der Erstellung eines digitalen Zertifikats für einen Geschäftspartner; die Erstellung von Zertifikaten wird von einer Zertifizierungsstelle vorgenommen, die einfach die Identität eines Geschäftspartners bestätigt. Dieser Bootstrapping-Prozess zur Herstellung von Vertrauensstellungen im Verbund bestätigt, dass die Identität des Partners, die beispielsweise in einem digitalen Zertifikat vorgegeben wird, an zuvor ausgehandelte geschäftliche oder rechtliche Vereinbarungen oder ähnliche Arten von Vereinbarungen gebunden ist.
Vorzugsweise ermöglicht die vorliegende Erfindung, dass eine Vertrauensbeziehung flexibel ist; zum Beispiel können Verbundpartner mit Hilfe von verschiedenen Arten von Sicherheits-Token interaktiv kommunizieren. Wie vorstehend mit Bezug auf 7 beschrieben wurde, kann eine Ausführungsform der vorliegenden Erfindung einen vertrauenswürdigen Dienst enthalten, der die Vertrauensbeziehungen zwischen einem bestimmten Unternehmen und seinen Geschäftspartnern verwaltet, während er die Funktionalität der Verwaltung von Vertrauensbeziehungen von der Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund trennt. In der Beschreibung von 7 wird jedoch die Art und Weise, in der die Vertrauensbeziehungen hergestellt werden, nicht weiter beschrieben.
11 zeigt eine Art und Weise, in der der vertrauenswürdige Dienst 704, beispielsweise der in 7 gezeigte vertrauenswürdige Dienst, die Datenverarbeitungsumgebung eines Verbundpartners 1102 funktional unterstützt, um eine Vertrauensbeziehung mit dem Verbundpartner 1104 herzustellen. Die Konsolenanwendung 1106 zur Verwaltung von Vertrauensbeziehungen in der Datenverarbeitungsumgebung 1102 stützt sich auf den vertrauenswürdigen Dienst 704, um einen Austausch von Daten mit einer Einheit am Verbundpartner 1104, beispielsweise einer ähnlichen Konfigurationsanwendung in der Datenverarbeitungsumgebung des Verbundpartners 1104, zu ermöglichen. Wie vorstehend beschrieben wurde, wird eine Vertrauensbeziehung zwischen zwei Partnern als ein Tupel mit sicherheitsbezogenen Daten dargestellt, insbesondere als ein Satz von Datenelementen, die {kryptografische Schlüssel, Sicherheits-Token und Identitätsumsetzungen} umfassen. Der vertrauenswürdige Dienst 704 ermöglicht somit den Austausch von Daten über erwartete Token-Formate 1108, kryptografische Schlüssel 1110 und Identitätsumsetzungen 1112, die dann von der Konsolenanwendung 1106 zur Verwaltung von Vertrauensbeziehungen oder vom vertrauenswürdigen Dienst 704 in der Datenbank für Vertrauensbeziehungen 1114 gespeichert werden. Es sei angemerkt, dass jede Vertrauensbeziehung, die in der Datenbank für Vertrauensbeziehungen 1114 dargestellt wird, über zusätzliche Informationen verfügen kann, um die Vertrauensbeziehung zu beschreiben oder zu realisieren.
Nun Bezug nehmend auf 12 zeigt ein Blockschaubild eine Konfiguration einer Datenverarbeitungsumgebung zur Einbindung einer Verbundfunktionalität. Wie vorstehend mit Bezug auf 10 erwähnt wurde, muss die Konfiguration der Verbundfunktionalität stattfinden, bevor eine Verbundtransaktion eingeleitet wird. Wie vorstehend mit Bezug auf 5 beschrieben wurde, umfasst die Anwendung 508 zur Lebenszyklusverwaltung des Benutzers im Verbund eine Unterstützungsfunktion, die dazu dient, mit Einschüben 514 zur Lebenszyklusverwaltung des Benutzers im Verbund, die ebenfalls in 12 gezeigt sind, eine Verbindung herzustellen, in Dialog zu treten oder in anderer Weise zusammenzuarbeiten.
In einer Ausführungsform der vorliegenden Erfindung stellen die Verbundprotokolllaufzeit-Einschübe die Funktionalität für verschiedene Arten von unabhängig voneinander veröffentlichten oder entwickelten Standards oder Profilen zur Lebenszyklusverwaltung des Benutzers im Verbund bereit. Bezug nehmend auf 12 verwendet ein Benutzer in seiner Funktion als Systemadministrator in einer Datenverarbeitungsumgebung eines Unternehmens die Konsolenanwendung 1202 zur Verwaltung der Laufzeitumgebung, um die FULM-Anwendung 508 und die Einschübe 514 zur Lebenszyklusverwaltung des Benutzers im Verbund zu verwalten. Der Administrator kann zum Beispiel eine grafische Benutzeroberfläche einsetzen, die von der Konsolenanwendung 1202 zur Verwaltung der Laufzeitumgebung bereitgestellt wird, um die Einschübe 514 in einem bestimmten Verzeichnis auf einem bestimmten Server zu konfigurieren. Wenn eine neue Verbundoperation unterstützt wird, kann der Administrator ein neues Zusatzprogramm verwenden, indem er das neue Zusatzprogramm in dem entsprechenden Verzeichnis speichert; eine aktualisierte Version des neuen Zusatzprogramms kann von der Verwaltungsanwendung von einem Drittanbieter, einer zentralisierten Verbunddatenbank oder von einer anderen Stelle abgerufen werden. Die Konfigurationsdateien und/oder Eigenschaften-Dateien enthalten Laufzeit-Parameter für die Einschübe 514 wie zum Beispiel URIs, die während Verbundtransaktionen verwendet werden sollen; diese können vom Administrator mittels der Konsolenanwendung 1202 zur Verwaltung der Laufzeitumgebung erzeugt, geändert und gelöscht werden.
Nun Bezug nehmend auf 13A zeigt ein Blockschaubild eine Konsolenanwendung zur Verwaltung von Verbundbeziehungen, die von einem Benutzer, der als Systemadministrator tätig ist, verwendet werden kann, um gemäß einer Ausführungsform der vorliegenden Erfindung Verbundbeziehungen in der Datenverarbeitungsumgebung eines Unternehmens herzustellen. Wie vorstehend erwähnt wurde, enthält eine Verbundbeziehung eine Auswahl an Verbundfunktionen, die zwischen Partnern vereinbart werden müssen; zum Beispiel kommen beide Partner überein, eine Einmalanmeldefunktion wirksam zu nutzen. Um diese Funktionen jedoch auszuführen, müssen beide Parteien auch die partnerspezifischen Daten für die ausgewählten Funktionen wie zum Beispiel die URI kennen, an die eine Einmalanmeldeanforderungs-/-antwortnachricht zu senden ist. Die partnerspezifischen Daten, die der eine Verbundpartner von dem anderen Verbundpartner erfassen muss, hängen von der Verbundfunktionalität ab, die von den Verbundpartnern für die jeweilige Verbundbeziehung festgelegt oder ausgewählt wurde. Diese partnerspezifischen Daten müssen zwischen den Partnern ausgetauscht werden.
Folglich kann eine einzige Konfigurationsformulardatei oder Vorlagendatei nicht von einem ersten Verbundpartner an alle Verbundpartner verteilt werden, da die Daten, die von jedem Verbundpartner benötigt werden, unterschiedlich sein können; die Daten, die zur Laufzeit benötigt werden, um eine Verbundtransaktion gemäß einer festgelegten Verbundbeziehung auszuführen, sind partnerspezifisch. Wenn ein Administrator an dem ersten Partner sein Konfigurationsformular oder seine Konfigurationsvorlage für jeden Verbundpartner nicht individuell auf der Grundlage der konfigurierten Funktionen ihrer jeweiligen Verbundbeziehung gestalten würde, müsste der andere Partner alle Daten, die in dem Konfigurationsformular beziehungsweise der Konfigurationsvorlage möglicherweise angefordert würden, ungeachtet dessen bereitstellen, ob sie für ihre jeweilige Verbundbeziehung erforderlich wären oder nicht.
Die vorliegende Erfindung wählt vorzugsweise einen Lösungsansatz, bei dem während des Aufbaus einer Verbundbeziehung eine verbundbeziehungsspezifische XML-Konfigurationsdatei dynamisch erzeugt und an den Verbundpartner exportiert wird, der die angeforderten partnerspezifischen Konfigurationsdaten zur Verfügung stellt und sie an den Anforderer zurückschickt. Nachdem die fertiggestellte Datei von einem Partner empfangen wurde, kann der anfordernde Partner die partnerspezifischen Konfigurationsdaten importieren und sie der entsprechenden Verbundbeziehung zuordnen, wie nachstehend ausführlicher erklärt wird.
Bezug nehmend auf 13A stellt ein als Administrator tätiger Benutzer eine Verbundbeziehung mit Hilfe der Konsolenanwendung 1300 zur Verwaltung einer Verbundbeziehung her. Da jede Verbundbeziehung eine Vertrauensbeziehung umfasst, ruft die Konsolenanwendung 1300 zur Verwaltung von Vertrauensbeziehungen Daten über zuvor hergestellte Vertrauensbeziehungen von der Datenbank für Vertrauensbeziehungen 1302 ab. Die Datenbank für Vertrauensbeziehungen 1302 enthält einen Eintrag für jede Vertrauensbeziehung, die zwischen einem Unternehmen und seinen vertrauenswürdigen Geschäftspartnern hergestellt wurde, wie beispielsweise vorstehend mit Bezug auf 11 erörtert wurde; die Datenbank für Vertrauensbeziehungen 1302 in 13A ist ähnlich der Datenbank für Vertrauensbeziehungen 1114 in 11; es sei angemerkt, dass Datenbanken, Konfigurationsdateien, Datenstrukturen usw., die hier beschrieben werden, in Form von gewöhnlichen Datenspeichern oder in Form von vielen verschiedenen Arten von Datenspeichern ausgeführt werden können, so dass jeder Datenspeicher als eine Datenbank, Datei, Datenstruktur usw. realisiert werden kann. In dem in 13A gezeigten Beispiel enthält die Datenbank für Vertrauensbeziehungen 1302 eine Vertrauensbeziehung mit dem Namen "Trust--XY", die durch den Eintrag 1304 in der Datenbank für Vertrauensbeziehungen dargestellt ist. Wie vorstehend beschrieben wurde, umfasst jede Vertrauensbeziehung ein Tupel mit Daten; der Eintrag 1304 in der Datenbank für Vertrauensbeziehungen enthält das Tupel 1306, das Daten 1308 über kryptografische Schlüssel, Daten 1310 über das Format des Token und Daten 1312 über die Identitätsumsetzung umfasst. Jede Vertrauensbeziehung umfasst auch zusätzliche partnerspezifische Daten, um die dargestellte Vertrauensbeziehung zu realisieren, zum Beispiel die Identitäten der Partner, die an der Vertrauensbeziehung teilnehmen, Daten über die Identität oder den Standort eines vertrauenswürdigen Dienstes, der kontaktiert werden kann, um Operationen in Bezug auf die Vertrauensbeziehung durchzuführen, oder andere ähnliche Arten von Daten.
Da eine Verbundbeziehung auch partnerspezifische Daten über die Verbundfunktionalität umfasst, die in der Verbundbeziehung unterstützt werden soll, ruft die Konsolenanwendung 1300 zur Verwaltung von Verbundbeziehungen auch verbundfunktionsspezifische Daten über die Verbundfunktionalität ab, die in der Datenverarbeitungsumgebung des Unternehmens möglicherweise schon konfiguriert wurde oder die in der Domäne oder Datenverarbeitungsumgebung des Unternehmens konfiguriert werden wird. Wenn man beispielsweise davon ausgeht, dass die Datenverarbeitungsumgebung des Unternehmens gemäß einer Ausführungsform der vorliegenden Erfindung ausgeführt wurde, die ähnlich der vorstehend mit Bezug auf 5 beschriebenen Ausführungsform ist, kann die Konsolenanwendung 1300 zur Verwaltung von Verbundbeziehungen Daten über eine FULM-Anwendung und/oder ihre zugehörigen Einschübe von verschiedenen Datenquellen abrufen, beispielsweise, indem sie Verzeichnisse durchsucht, die diese Dateien enthalten, indem sie Konfigurations- und/oder Eigenschaften-Dateien 1314 liest, die zu der FULM-Anwendung und/oder ihren zugehörigen Einschüben gehören, oder sie kann diese Daten in anderer Weise abrufen. In einer Ausführungsform kann die Konsolenanwendung 1300 zur Verwaltung von Verbundbeziehungen im Anschluss an die Erfassung dieser Daten die Registrierdatenbank 1316 aufbauen, bei der es sich um eine Sammlung von Daten über die Verbundfunktionalität handelt, die in der Domäne oder in der Datenverarbeitungsumgebung des Unternehmens unterstützt wird oder die der Domäne oder der Datenverarbeitungsumgebung des Unternehmens zur Verfügung steht. In dem in 13A gezeigten Beispiel enthält die Registrierdatenbank 1316 den Eintrag 1318 für eine Art einer zur Verfügung stehenden Verbundfunktion; der Eintrag 1318 in der Registrierdatenbank ist auch mehreren Feldern 1320 zugeordnet, die die diversen Metadaten-Parameter darstellen, die von einer bestimmten Verbundfunktion benötigt werden; die Metadaten geben die partnerspezifischen Konfigurationsdaten an, die ein Verbundpartner benötigt, um die bestimmte Verbundfunktion während einer Instanz einer Verbundtransaktion, welche von der Verbundfunktion Gebrauch macht, aufzurufen oder zu verwalten. In einer Ausführungsform ist die Registrierdatenbank 1316 ein vorübergehender Datenspeicher oder eine vorübergehende Datenstruktur, die jedes Mal dynamisch erzeugt wird, wenn die Konsolenanwendung 1300 zur Verwaltung von Verbundbeziehungen von einem als Administrator tätigen Benutzer verwendet wird; in einer alternativen Ausführungsform wird die Registrierdatenbank 1316 von einem anderen Konfigurations-Dienstprogramm in der Domäne oder der Datenverarbeitungsumgebung des Unternehmens verwaltet, beispielweise von einer Konsolenanwendung 1202 zur Verwaltung der Laufzeitumgebung, die in 12 gezeigt ist.
In manchen Fällen würden Informationen über die Metadaten-Parameter, die zu einer Verbundfunktion gehören, zum Zeitpunkt der Erzeugung der Software-Module, die die Verbundfunktion ausführen, ermittelt werden; anders ausgedrückt, diese Metadaten-Parameter sind verbundfunktionsspezifisch und in einer bestimmten Weise den Software-Modulen zugeordnet, die diese Verbundfunktionen ausführen. Daher sollte die Identität der Metadaten-Parameter 1320, die einer Verbundfunktion zugeordnet sind, den Software-Modulen, die die Verbundfunktion ausführen, vorzugsweise als funktionsspezifische Metadaten-Parameter in Konfigurations- und/oder Eigenschaften-Dateien 1314 beigefügt werden; diese Konfigurations- und/oder Eigenschaften-Dateien 1314 werden zu dem Zeitpunkt, zu dem die Software-Module eingesetzt werden, z. B. wenn eine FULM-Anwendung und/oder ihre Einschübe eingesetzt werden, in der Datenverarbeitungsumgebung eines Unternehmens eingesetzt oder konfiguriert. Alternativ dazu können die Anzahl und die Art der Metadaten-Parameter 1320 von einer anderen Datenquelle, beispielsweise einer gemeinsamen zentralisierten Verbunddatenbank, abgerufen werden. Bei noch einer weiteren Alternative können die Anzahl und die Art der Metadaten-Parameter 1320 von elektronischen Dateien abgeleitet werden, die die Spezifikation eines Verbundprotokolls beschreiben; die Spezifikationsdateien können einen Standardsatz von Metadaten-Parametern so beschreiben, dass jede Ausführung einer Verbundfunktion für eine Verbundfunktion, die das jeweilige Verbundprotokoll einhält, bestimmte Metadaten-Parameter benötigt, wodurch die Schnittstelle oder der zu erwartende Datenaustausch gezwungenermaßen von Software-Modulen für das Verbundprotokoll realisiert wird. In jedem Fall stehen die Anzahl und die Art der Metadaten-Parameter 1320 zum Abruf durch die Konsolenanwendung 1300 zur Verwaltung von Verbundbeziehungen bereit.
Die Konsolenanwendung 1300 zur Verwaltung von Verbundbeziehungen ruft Daten über Vertrauensbeziehungen und die Verbundfunktionalität ab, während sie einen als Administrator tätigen Benutzer bei der Herstellung einer Verbundbeziehung unterstützt. Diese Verbundbeziehungen werden durch Einträge in der Datenbank 1322 für Verbundbeziehungen dargestellt. In dem in 13A gezeigten Beispiel stellt der Eintrag 1324 in der Datenbank für Verbundbeziehungen eine Verbundbeziehung mit der Bezeichnung "Fed--XY--ProjectX" dar; in diesem Beispiel gibt die Kennung für die Verbundbeziehung einen Hinweis auf die Verbundpartner, die in der Verbundbeziehung zusammenarbeiten, z. B. den Partner "X" und den Partner "Y", sowie einen Hinweis auf den Zweck der Verbundbeziehung. In Anbetracht dessen, dass Verbundpartner gegebenenfalls aus vielen verschiedenen Gründen miteinander kommunizieren und dass jeder Grund seine eigenen Anforderungen stellen kann, ist es möglich, dass zwei als Paar zugeordnete Verbundpartner eine Vielzahl von Verbundbeziehungen haben können, wie vorstehend mit Bezug auf die 9A bis 9B beschrieben wurde.
In dem in 13A gezeigten Beispiel wurde der Eintrag 1304 in der Datenbank für Vertrauensbeziehungen in Form der Daten 1326 über die Vertrauensbeziehung in den Eintrag 1324 der Datenbank für Verbundbeziehungen kopiert, wobei diese Daten die Vertrauensbeziehung-Tupel 1328 umfassen, welches die kryptografischen Schlüssel 1330, Daten über das Token-Format 1332 und Identitäts-/Attribut-Umsetzungsdaten 1334 enthält. Alternativ dazu kann der Eintrag 1324 in der Datenbank für Verbundbeziehungen lediglich einen Verweis oder einen Zeiger auf den Eintrag 1304 in der Datenbank 1302 für Vertrauensbeziehungen speichern, so dass der Eintrag 1304 in der Datenbank für Vertrauensbeziehungen geändert werden kann, ohne dass dies eine Aktualisierung am Eintrag 1324 in der Datenbank für Verbundbeziehungen erforderlich macht; einzelne Datenelemente, die die Elemente einer Vertrauensbeziehung wie zum Beispiel kryptografische Schlüssel und Zertifikate umfassen, können ebenfalls lediglich nur durch einen Verweis eingebunden werden, um die Verwaltung dieser Datenelemente leistungsfähiger zu gestalten. Der Eintrag 1324 in der Datenbank für Verbundbeziehungen enthält auch Daten über die Verbundoperationen/-funktionen, die von der Verbundbeziehung unterstützt werden sollen, welche von dem Eintrag 1324 in der Datenbank für Verbundbeziehungen dargestellt wird, z. B. über die Funktionen 1336 und 1338 beziehungsweise über die zugehörigen Metadaten-Informationen 1340 und 1342 über ihre Ausführungsvoraussetzungen; alternativ dazu kann der Eintrag 1324 in der Datenbank für Verbundbeziehungen lediglich Verweise oder Zeiger auf entsprechende Speicherplätze wie zum Beispiel die Konfigurations- und/oder Eigenschaften-Dateien 1314 speichern, aus denen Daten über unterstützte Verbundfunktionen/-operationen abgerufen werden können.
Zu einem bestimmten zukünftigen Zeitpunkt wird der Eintrag 1324 in der Datenbank für Verbundbeziehungen verwendet, um eine Verbundtransaktion einzuleiten, die von der Verbundfunktionalität Gebrauch macht, die im Eintrag 1324 der Datenbank für Verbundbeziehungen angegeben ist, d. h. von den Funktionen 1336 und 1338. Um die Verbundtransaktion jedoch einleiten oder durchführen zu können, müssen partnerspezifische Daten in denjenigen Fällen verwendet werden, in denen die Verbundfunktionalität durch ihre Metadaten-Informationen, d. h. entsprechend den Informationen 1340 und 1342, die zu den Funktionen 1336 und 1338 gehören, anzeigt, dass sie partnerspezifische Daten benötigt. Diese partnerspezifischen Daten können beispielsweise eine oder mehrere URIs enthalten, die die Ziele von Anforderungsnachrichten angeben, die an einen Verbundpartner gesendet werden müssen, um eine Verbundtransaktion mit eben diesem Verbundpartner anzufordern.
Während ein als Administrator tätiger Benutzer bei einer Ausführungsform der vorliegenden Erfindung eine Verbundbeziehung mittels der Konsolenanwendung 1300 zur Verwaltung von Verbundbeziehungen oder mittels eines ähnliches Software-Werkzeugs für Verwaltungszwecke aufbaut oder herstellt, versucht die Konsolenanwendung 1300 zur Verwaltung von Verbundbeziehungen, die partnerspezifischen Daten abzurufen und diese dann im Eintrag 1324 der Datenbank für Verbundbeziehungen als partnerspezifische Datenelemente, d. h. als die Datenelemente 1344 und 1346, zu speichern. Dazu erzeugt die Konsolenanwendung 1300 zur Verwaltung von Verbundbeziehungen dynamisch die Vorlagendatei 1348 zur Herstellung von Verbundbeziehungen; diese kann eine XML-formatierte Datei oder eine andere Art von Datei sein. Die Vorlage 1348 wird von dem Partner, von dem sie stammt, z. B. vom Partner "X", an den vertrauenswürdigen Partner gesendet, mit dem der als Administrator tätige Benutzer versucht, eine Verbundbeziehung herzustellen, z. B. an den Partner "Y", wie in den Daten 1326 über die Vertrauensbeziehung angegeben ist. Wenn der vertrauenswürdige Partner die benötigten partnerspezifischen Daten bereitgestellt hat, indem er die Vorlagendatei 1348 so geändert hat, dass die Daten darin enthalten sind, importiert die Konsolenanwendung 1300 zur Verwaltung von Verbundbeziehungen an dem anfordernden Partner die geänderte Vorlagendatei 1348, entnimmt ihr die bereitgestellten Daten und speichert sie in dem Eintrag 1324 der Datenbank für Verbundbeziehungen, wie nachstehend ausführlicher erklärt wird.
Es sei angemerkt, dass partnerspezifische Konfigurationsdaten gegebenenfalls auch von der Datenverarbeitungsumgebung des vorstehend erwähnten Benutzers, der als Administrator tätig ist, d. h. dem Ursprungs-/Quellenpartner oder dem Partner "X", an den kooperierenden/Ziel-Verbundpartner, d. h. den Partner "Y", übertragen werden müssen. Der Ziel-Verbundpartner benötigt möglicherweise bestimmte partnerspezifische Daten über den Ursprungspartner, um die Verbundbeziehung aus der Sicht des kooperierenden/Ziel-Verbundpartners zu konfigurieren; beispielsweise könnte der Verbundpartner ähnliche Metadaten-Informationen, wie zum Beispiel URIs des Kontaktservers, benötigten, so dass der kooperierende/Ziel-Verbundpartner unter Verwendung der Verbundfunktionalität in Verbindung mit den partnerspezifischen Konfigurationsdaten eine Verbundtransaktion in die entgegengesetzte Richtung zu der Domäne des als Administrator tätigen Benutzers, z. B. zu dem Partner "X", einleiten kann, welches der Verbundpartner ist, der in diesem Beispiel ursprünglich den Aufbau der Verbund-Partnerschaft zwischen den beiden Partnern eingeleitet hat. Folglich kann die Vorlagendatei 1348 auch partnerspezifische Daten für die Domäne des als Administrator tätigen Benutzers, d. h. den Partner "X", enthalten. Alternativ dazu können die partnerspezifischen Daten für den Ursprungspartner, d. h. den Partner "X", in einer Begleitdatei oder in einer anschließend übertragenen Datei übertragen werden, so dass zwei Dateien zum Transport der partnerspezifischen Daten zwischen den Partnern verwendet werden. Die partnerspezifischen Daten, die von dem Ursprungs-/Quellenpartner an den kooperierenden/Ziel-Verbundpartner übertragen werden, könnten von dem als Administrator tätigen Benutzer über die Konsolenanwendung 1300 zur Verwaltung von Verbundbeziehungen eingegeben werden, während der als Administrator tätige Benutzer die Vertrauensbeziehung aufbaut, oder ein Teil der Daten beziehungsweise die gesamten Daten könnten aus einer Konfigurationsdatenbank abgerufen werden, die ebenfalls von der Konsolenanwendung 1300 zur Verwaltung von Verbundbeziehungen verwaltet wird.
Es sei jedoch angemerkt, dass die partnerspezifischen Daten, die in der vorstehend beschriebenen Weise zwischen den Verbundpartnern ausgetauscht werden, unsymmetrisch sein können. Anders ausgedrückt, die Verbundpartner können sich an einer Verbundtransaktion beteiligen, indem sie ganz unterschiedliche Aufgaben übernehmen, und diese unterschiedlichen Aufgaben können es erforderlich machen, dass ihren jeweiligen Verbundpartnern verschiedene Arten von Daten zur Verfügung gestellt werden. Der als Administrator tätige Benutzer kann zum Beispiel ein Unternehmen betreiben, das die Funktion eines Identitätsanbieters hat. Die Verbundbeziehung kann einen Teil der Funktionalität unterstützen, die von den Liberty-ID-FF-Spezifikationen der Liberty Alliance festgelegt ist. In diesem Szenario kann die Verbundfunktionalität Folgendes einschließen: Browser-/Artefakt-Einmalanmeldung; vom Identitätsanbieter eingeleitetes Versenden der Registernamenskennung auf der Grundlage einer HTTP-Umleitung (identity-provider-initiated HTTP-Redirect-based Register Name Identifier); und vom Diensteanbieter eingeleitete SOAP/HTTP-Benachrichtung über die Aufhebung eines Verbunds (service-provider-initiated SOAP/HTTP Federation Termination Notification). Bei dieser besonderen Verbundfunktionalität können die Arten der partnerspezifischen Daten, die einem Diensteanbieter von dem Identitätsanbieter bereitgestellt werden, von den Arten der partnerspezifischen Daten abweichen, die dem Identitätsanbieter vom Diensteanbieter bereitgestellt werden. Wenn die partnerspezifischen Daten entsprechend der in Bezug auf eine Verbundbeziehung übernommenen Aufgabe eines Verbundpartners abweichen, würde der als Administrator tätige Benutzer die Konsolenanwendung 1300 zur Verwaltung von Verbundbeziehungen über die Aufgabe informieren, die von dem Unternehmen des als Administrator tätigen Benutzers durchzuführen ist, wobei davon ausgegangen wird, dass diese Aufgabe nicht zuvor konfiguriert wurde oder in einer Konfigurationsdatei oder in der Datenbank für die Verwaltung von Verbundbeziehungen gespeichert worden ist; der als Administrator tätige Benutzer kann die Konsolenanwendung zur Verwaltung von Verbundbeziehungen informieren, indem er eine entsprechende Datenoption auf einer grafischen Benutzeroberfläche (GUI), die die Konsolenanwendung zur Verwaltung von Verbundbeziehungen bereitstellt, auswählt oder diese eingibt, wie beispielsweise in 13B gezeigt ist.
Nun Bezug nehmend auf 13B zeigt eine schematische Darstellung ein Fenster einer grafischen Benutzeroberfläche in einer Anwendung zur Verwaltung von Verbundbeziehungen, das von einem als Administrator tätigen Benutzer gemäß einer Ausführungsform der vorliegenden Erfindung zur Herstellung einer Verbundbeziehung zwischen Verbundpartnern verwendet werden kann. Das Dialogfenster 1350 enthält das Aufklappmenü 1352, um einem Benutzer die Auswahl einer Vertrauensbeziehung zu ermöglichen, auf deren Grundlage er die Verbundbeziehung aufbauen kann, die von einer Konsolenanwendung zur Verwaltung von Verbundbeziehungen, zum Beispiel der in 13A gezeigten Konsolenanwendung 1300 zur Verwaltung von Verbundbeziehungen, hergestellt wird. Alternativ dazu ist es dem Benutzer gegebenenfalls möglich, beispielsweise durch Auswahl eines Menüpunkts oder durch Anklicken einer Dialogschaltfläche, in der Konsolenanwendung zur Verwaltung von Verbundbeziehungen oder in einer anderen Anwendung, zum Beispiel der Konsolenanwendung 1106 zur Verwaltung von Vertrauensbeziehungen, die in 11 gezeigt ist, Funktionen aufzurufen, um bei Bedarf dynamisch eine neue Vertrauensbeziehung für eben diese Verbundbeziehung aufzubauen. Der Aufbau einer Vertrauensbeziehung kann die Verwendung vorhandener Daten für das Unternehmen des als Administrator tätigen Benutzers wie zum Beispiel vorhandene private Schlüssel, digitale Zertifikate, Token, Identitätsabbildungs-Daten usw. einschließen; der als Administrator tätige Benutzer könnte dann den verbleibenden Teil der Vertrauensbeziehung unter Verwendung von bekannten Daten für den vertrauenswürdigen Partner, sofern verfügbar, konfigurieren, zum Beispiel unter Verwendung von öffentlichen Schlüsseln, digitalen Zertifikaten, Identitätsabbildungsdaten usw., obgleich Token-Daten nicht konfiguriert werden, da diese Daten von jedem Partner so konfiguriert werden, dass sie unveränderlich sind.
Über das Aufklappmenü 1354 kann ein Benutzer die Verbundfunktionen auswählen, die in der Verbundbeziehung, die gerade hergestellt wird, unterstützt werden sollen. Das Texteingabefeld 1356 kann zur Eingabe eines Namens für die Verbundbeziehung, die gerade hergestellt wird, verwendet werden. Die Schaltfläche 1358 schließt das Dialogfenster und fährt mit dem Aufbau der Verbundbeziehung fort, indem sie einen Eintrag in einem entsprechenden Datenspeicher erzeugt, beispielsweise in einer Weise, die ähnlich der in 13A gezeigten ist; die Schaltfläche 1360 schließt das Dialogfenster und bricht die Herstellung einer Verbundbeziehung ab. Wenn der als Administrator tätige Benutzer beispielsweise die Schaltfläche 1358 auswählt, leitet die Konsolenanwendung die Übertragung von partnerspezifischen Konfigurationsdaten zwischen den beiden Partnern ein, die an der Verbundbeziehung teilnehmen, indem sie zum Beispiel die Vorlagendatei zur Herstellung von partnerspezifischen Verbundbeziehungen, die vorstehend erwähnt wurde und nachstehend ausführlicher beschrieben wird, exportiert und anschließend importiert.
Nun Bezug nehmend auf die 13C bis 13D zeigt ein Blockschaubild Datenflüsse, die von einer Konsolenanwendung zur Verwaltung von Verbundbeziehungen gestartet werden, um zur Herstellung von Verbundbeziehungen in der Datenverarbeitungsumgebung eines Unternehmens gemäß einer Ausführungsform der vorliegenden Erfindung partnerspezifische Daten zu erhalten. Wir vorstehend mit Bezug auf 13A angemerkt wurde, erzeugt die Konsolenanwendung 1300 zur Verwaltung von Verbundbeziehungen dynamisch die Vorlagendatei 1348 zur Herstellung von Verbundbeziehungen. Beispielsweise kann die Konsolenanwendung 1300 zur Verwaltung von Verbundbeziehungen die Vorlage 1348 erzeugen, nachdem der Benutzer über das in 13B gezeigte Dialogfenster 1350 die Anwendung dazu angewiesen hat. Der Inhalt der Vorlage 1348 wird auf der Grundlage der Verbundbeziehung dynamisch ermittelt, für die die Konsolenanwendung 1300 zur Verwaltung von Verbundbeziehungen versucht, partnerspezifische Daten zu erhalten. Bezug nehmend auf 13C erstellt die Konsolenanwendung 1300 zur Verwaltung von Verbundbeziehungen die Vorlage 1348 auf der Grundlage der Verbundbeziehung, die von dem Eintrag 1324 in der Datenbank für Verbundbeziehungen dargestellt wird. Ähnlich wie in 13A enthält der Eintrag 1324 in der Datenbank für Verbundbeziehungen Daten über die Verbundoperationen/-funktionen, die von der Vertrauensbeziehung unterstützt werden sollen, welche von dem Eintrag 1324 in der Datenbank für Verbundbeziehungen dargestellt wird, z. B. über die Funktion 1336, sowie zugehörige Metadaten-Informationen 1340 über die Parameter, die zur Durchführung der zugehörigen Funktion erforderlich sind. Wenn die Konsolenanwendung 1300 zur Verwaltung von Verbundbeziehungen die Vorlage 1348 erzeugt, entnimmt die Anwendung Metadaten-Informationen 1340 und erzeugt aus dem Eintrag 1324 in der Datenbank für Verbundbeziehungen nach Bedarf Felder oder Elemente 1354, wenn möglich als aus einem Namen und einem Wert bestehende Paare, in der Vorlage 1348 für die angegebenen Metadaten-Parameterelemente; wenn die Vorlage 1348 eine auf XML beruhende Datei ist, können die Namen-Wert-Paare als gekennzeichnete Elemente in die Datei aufgenommen werden. An diesem Punkt enthält die Vorlage 1348 noch keine partnerspezifischen Daten; zu einem späteren Zeitpunkt wird die Vorlage 1348 an einen kooperierenden/Ziel-Verbundpartner übertragen, um die partnerspezifischen Daten zu erhalten, die notwendig sind, um zukünftig eine Verbundtransaktion mit dem kooperierenden/Ziel-Verbundpartner auszuführen.
Bezug nehmend auf 13D enthält die Vorlage 1348 geänderte Namen-Wert-Paare 1356, nachdem der kooperierende/Ziel-Verbundpartner die Vorlage 1348 zurückgeschickt hat; der kooperierende/Ziel-Verbundpartner hat die Vorlage 1348 ausgewertet, die Anforderungen für die Namen-Wert-Paare entnommen und dann die benötigten Werte erhalten, möglicherweise im Wege einer automatischen Verarbeitung, möglicherweise aber auch durch den Dialog mit einem als Administrator tätigen Benutzer über eine an dem kooperierenden/Ziel-Verbundpartner befindliche Anwendung mit grafischer Benutzeroberfläche. Anschließend entnimmt die Konsolenanwendung 1300 zur Verwaltung von Verbundbeziehungen am Ursprungs-/Quellen-Verbundpartner die zurückgeschickten Namen-Wert-Paare 1356 und speichert die partnerspezifischen Daten, die von dem kooperierenden/Ziel-Verbundpartner bereitgestellt wurden, als die Datenelemente 1358 bis 1362 im Eintrag 1324 der Datenbank für Verbundbeziehungen. Die Datenelemente 1358 bis 1362 werden dann später zur Durchführung einer Verbundtransaktion mit dem Verbundpartner verwendet. Die partnerspezifischen Konfigurationsdaten über den Ursprungs-/Quellen-Verbundpartner können ebenfalls in der Vorlage 1348 an den Verbundpartner übertragen werden, so dass der Verbundpartner über gleichwertige oder entsprechende Daten verfügt, um anschließend eine ähnliche Verbundtransaktion in der entgegengesetzten Richtung einzuleiten oder um sich lediglich an einer Verbundtransaktion zu beteiligen; auf diese Weise wird eine einzige Datei hin und her übertragen, obwohl sie vor ihrer Rücksendung geändert wurde.
Alternativ dazu können partnerspezifische Konfigurationsdaten über den Ursprungs-/Quellen-Verbundpartner, d. h. den Verbundpartner, der die Verbundbeziehung zwischen den beiden Partnern aufgebaut hat, in einer zweiten Nachricht oder Datei übertragen werden, und zwar entweder gleichzeitig mit der Übertragung der ersten Datei oder zu einem anderen Zeitpunkt; diese zweite Datei stellt dem kooperierenden/Ziel-Verbundpartner partnerspezifische Daten über den Ursprungs-/Quellen-Verbundpartner zur Verfügung und wird nicht zurückgeschickt. Die erste Datei wird zum Beispiel als eine "leere" Datei an den Verbundpartner gesendet, der naturgemäß um die Aufnahme von partnerspezifischen Daten von dem kooperierenden/Ziel-Verbundpartner ersucht, die dann mit Änderungen zurückgeschickt werden, so dass die erste Datei partnerspezifische Daten für den Verbundpartner enthält. Im Gegensatz dazu wird die zweite Datei an den Verbundpartner als eine "volle" Datei gesendet, die dem kooperierenden/Ziel-Verbundpartner partnerspezifische Daten von dem Ursprungs-/Quellen-Verbundpartner zur Verfügung stellt.
Mit Bezug auf 14 zeigt ein Flussdiagramm einen Prozess, durch den automatisch eine Verbundbeziehung hergestellt wird, indem eine exportierte/importierte Datei verwendet wird, die zwischen Verbundpartnern ausgetauscht wird, die gemäß einer Ausführungsform der vorliegenden Erfindung über die Verbundbeziehung interaktiv miteinander kommunizieren. Der Prozess beginnt, wenn ein als Administrator tätiger Benutzer in der Datenverarbeitungsumgebung eines bestimmten Unternehmens, der z. B. als Partner "X" ausgewiesen ist, eine Mitteilung empfängt, dass er eine Verbundbeziehung mit einem vertrauenswürdigen Partner herstellen soll, der z. B. als Partner "Y" ausgewiesen ist (Schritt 1402). Zwar kann die Mitteilung bandextern empfangen werden, doch wird sie vorzugsweise elektronisch mittels eMail oder in einer bestimmten Weise in einer Verwaltungs-Konsolenanwendung wie zum Beispiel der Konsolenanwendung zur Verwaltung von Verbundbeziehungen, die in 13A gezeigt ist, empfangen, obgleich dies auch manuell, beispielsweise auf dem Postwege oder per Telefon, stattfinden kann. Im Allgemeinen haben Verbunde häufig die Vorstellung von einem Hauptförderer (power sponsor), bei dem es sich um einen Verbundpartner handelt, der die Funktion eines Ursprungs-/Quellenpartners übernimmt, um die Daten für eine Verbundbeziehung zu konfigurieren.
Falls noch nicht geschehen, ruft der als Administrator tätige Benutzer die Konsolenanwendung zur Verwaltung von Verbundbeziehungen auf (Schritt 1404). Alternativ dazu könnte diese Funktionalität durch Maßnahmen vom Typ Arbeitsablaufsteuerung eingeleitet und/oder durchgeführt werden, die von einer Anwendung in der Datenverarbeitungsumgebung des Ursprungs-/Quellen-Verbundpartners gestartet werden. Folglich könnte der in 14 gezeigte Prozess vollkommen automatisiert werden, vorzugsweise auf der Grundlage von Richtlinien-Entscheidungen, die in die Infrastruktur der Datenverarbeitungsumgebung eingebunden werden, zum Beispiel, indem möglicherweise Funktionen verwendet werden, die zur Umsetzung von WS-Policy-Spezifikationen konfiguriert wurden.
Es sei angemerkt, dass der in 14 gezeigte Prozess aus der Sicht des Ursprungs-/Quellen-Verbundpartners, des Verbundpartners "X", dargestellt ist, und dass die Prozessschritte, die mit Bezug auf 14 beschrieben sind, in der Datenverarbeitungsumgebung des kooperierenden/Ziel-Verbundpartners, des Verbundpartners "X", stattfinden; ähnliche Aktionen können am Verbundpartner "Y" als Reaktion auf den Empfang von Daten vom Verbundpartner "X" stattfinden, wie nachstehend ausführlicher beschrieben wird.
Der als Administrator tätige Benutzer leitet die Konfiguration oder den Aufbau einer neuen Verbundbeziehung (Schritt 1406) in der Konsolenanwendung zur Verwaltung von Verbundbeziehungen des Verbundpartners "X" ein; der Benutzer gibt einen Namen oder eine Kennung für die neue Verbundbeziehung ein (Schritt 1408), z. B., "Fed--XY--PROJECTX", oder der Name beziehungsweise die Kennung wird automatisch auf der Grundlage von einem Satz von Daten erzeugt, wie zum Beispiel den Partnern, die die Verbundbeziehung herstellen, usw.
Wenn die Operation zur Konfiguration/zum Aufbau der Verbundbeziehung automatisch über einen Arbeitsablaufprozess eingeleitet wird, kann die empfangene Anforderungsnachricht oder ein ähnliches einleitendes Ereignis einen Hinweis auf die Verbundfunktionalität enthalten, die in der angeforderten Verbundbeziehung unterstützt werden soll; alternativ oder zusätzlich hierzu kann der Benutzer die entsprechenden Verbundfunktionen in der Konsolenanwendung zur Verwaltung von Verbundbeziehungen auswählen (Schritt 1410), z. B. wie in 13B gezeigt ist, oder die empfangene Anforderungsnachricht kann automatisch verarbeitet werden, um die angeforderte Verbundfunktionalität festzustellen.
Der Benutzer wählt dann eine Vertrauensbeziehung aus, konfiguriert eine Vertrauensbeziehung oder baut eine Vertrauensbeziehung auf, auf der die Verbundbeziehung beruhen soll (Schritt 1412), wie beispielsweise in 13B gezeigt ist. Wenn zwischen den Partnern nur eine einzige Vertrauensbeziehung besteht, kann die Vertrauensbeziehung automatisch ausgewählt werden; wenn keine der bereits bestehenden Vertrauensbeziehungen für die ausgewählte Verbundfunktionalität geeignet ist, kann die Konsolenanwendung zur Verwaltung von Verbundbeziehungen den Benutzer auffordern, eine neue Vertrauensbeziehung zu konfigurieren oder aufzubauen.
Wie nachstehend ausführlicher erklärt wird, kann eine Vertrauensbeziehung zwischen zwei Geschäftspartnern zur selben Zeit konfiguriert oder aufgebaut werden, zu der auch eine Verbundpartnerschaft zwischen diesen beiden Geschäftspartnern konfiguriert oder aufgebaut wird. Daher können Daten zur Konfiguration einer Vertrauensbeziehung zwischen den Geschäftspartnern während des gleichen Zeitraums übertragen werden, in dem Daten zur Konfiguration einer Verbundbeziehung übertragen werden.
Im Gegensatz dazu kann zwischen den Verbundpartnern, die eine Verbundbeziehung konfigurieren, jedoch bereits eine Vertrauensbeziehung bestehen. Diese Vertrauensbeziehung kann aus einem anderen Grund als zum Zweck der Zusammenarbeit in einem Verbund konfiguriert worden sein. Diese Vertrauensbeziehung wurde möglicherweise durch einen einfachen Datenaustausch konfiguriert; alternativ dazu wurde diese Vertrauensbeziehung möglicherweise mittels anderer Software-Anwendungen in ihren jeweiligen Datenverarbeitungsumgebungen, jedoch unter Nichtberücksichtigung von Verbund-Aspekten, konfiguriert. Beispielsweise haben die Verbundpartner vielleicht schon öffentliche Schlüssel/digitale Zertifikate und andere vertrauensbezogene Daten ausgetauscht, die sie für eine beliebige Transaktion zwischen ihnen verwenden möchten; diese Daten wurden möglicherweise mittels einer einfachen Übertragung von elektronischen Daten, durch eine andere Art von Software-Anwendung oder auf andere Weise ausgetauscht.
Überdies gibt es vielleicht schon eine bereits vorhandene Vertrauensbeziehung, die zum Zweck der Kommunikation innerhalb des Verbunds aufgebaut wurde. Anders ausgedrückt, wenn man davon ausgeht, dass zwei als Paar zugeordnete Geschäftspartner durch mehrere gleichzeitige Verbundbeziehungen zusammenarbeiten, wurde eine Vertrauensbeziehung möglicherweise schon für eine zuvor hergestellte Verbundbeziehung aufgebaut.
In jedem Fall kann es zwischen den beiden Geschäftspartnern, die eine neue Verbundbeziehung aufbauen oder konfigurieren möchten, bereits eine oder mehrere Vertrauensbeziehungen geben, und zwar ungeachtet dessen, ob zwischen den beiden Partnern bereits schon eine Verbundbeziehung besteht. Wenn es mindestens eine bereits vorhandene Vertrauensbeziehung gibt, können die vertrauensbezogenen Daten in einer Vertrauensbeziehung logisch zu einer unverwechselbaren benannten Vertrauensbeziehung gepackt werden, die in der Konsolenanwendung zur Verwaltung von Verbundbeziehungen dargestellt werden kann; wenn dies der Fall ist, kann der als Administrator tätige Benutzer diese bereits vorhandene, formal definierte Vertrauensbeziehung in einer grafischen Benutzeroberfläche einfach auswählen.
Alternativ dazu können die vertrauensbezogenen Daten für eine oder mehrere bereits vorhandene Vertrauensbeziehungen dem als Administrator tätigen Benutzer als getrennte Datenelemente von vertrauensbezogenen Daten in einer grafischen Benutzeroberfläche dargestellt werden. In diesem Szenario kann der Benutzer eine neue Vertrauensbeziehung aufbauen, indem er die Datenelemente auswählt, die in der neuen Vertrauensbeziehung verwendet werden sollen; zum Beispiel kann ein einziges digitales Zertifikat in mehreren Vertrauensbeziehungen verwendet werden, da andere vertrauensbezogene Daten bei den diversen Vertrauensbeziehungen unterschiedlich sein können, was die verschiedenen Vertrauensbeziehungen unverwechselbar macht, obwohl bei jeder dasselbe digitale Zertifikat verwendet wird.
Bei noch einer anderen Alternative gibt es zwischen den Partnern möglicherweise keine bereits bestehende Vertrauensbeziehung. In diesem Szenario gibt der als Administrator tätige Benutzer die "Eigen"-Daten des Partners ein oder wählt sie aus, d. h. vertrauenswürdige Daten über den Ursprungs-/Quellenpartner; dabei kann es sich um partnerspezifische Daten wie beispielsweise ein digitales Zertifikat handeln, aber sie können auch bevorzugte Eigenschaften für die Vertrauensbeziehung beinhalten, die durch einfache Werte dargestellt werden können, die nicht partnerspezifisch sind und in verschiedenen vertrauensbezogenen Protokollspezifikationen angegeben sein können. Zum Beispiel könnte der als Administrator tätige Benutzer unter mehreren asymmetrischen kryptografischen Schlüsselpaaren wählen, die die Konsolenanwendung zur Herstellung von Verbundbeziehungen aus einem Schlüsselspeicher in der Datenverarbeitungsumgebung des Partners abgerufen hat; überdies könnte der Benutzer verschiedene Parameter, die für die Vertrauensbeziehung charakteristisch sind, über Kontrollkästchen, Optionsfelder, Menüs, usw. auf einer grafischen Benutzeroberfläche auswählen, wobei diese für die Vertrauensbeziehung charakteristischen Parameter verschiedene Verarbeitungsoptionen in Bezug auf die vertrauensbezogenen Daten angeben.
In Anbetracht dessen, dass eine Vertrauensbeziehung einen Dialog zwischen Partnern voraussetzt, würde die getroffene Auswahl bei den partnerspezifischen vertrauensbezogenen Daten zusammen mit der getroffenen Auswahl bei den verschiedenen vertrauensbezogenen Eigenschaften die partnerspezifischen vertrauensbezogenen Daten bestimmen, die der Ursprungs- /Quellenpartner von dem kooperierenden/Zielpartner benötigt. Anders ausgedrückt, die Daten, die zwischen den Partnern ausgetauscht werden, müssen in irgendeiner Weise übereinstimmen. Somit führt die Auswahl, die der als Administrator tätige Benutzer getroffen hat, anschließend dazu, dass die partnerspezifischen vertrauensbezogenen Daten des Ursprungs-/Quellenpartners in eine Vorlage/Konfigurationsdatei/Dateien aufgenommen werden, die an den kooperierenden/Zielpartner exportiert werden; darüber hinaus führt die Auswahl, die der als Administrator tätige Benutzer getroffen hat, anschließend auch dazu, dass datenanfordernde Elemente in die Vorlage/Konfigurationsdatei/Dateien aufgenommen werden, die von dem Ursprungs-/Quellenpartner an den kooperierenden/Zielpartner exportiert werden. In manchen Fällen benötigt die Verbundfunktionalität möglicherweise keine Unterstützung in Form von einer Vertrauensbeziehung, so dass keine Vertrauensbeziehung ausgewählt werden müsste; da eine Verbundbeziehung definitionsgemäß jedoch eine Vertrauensbeziehung umfasst, kann die Verbundbeziehung in diesem Szenario als eine Verbundbeziehung beschrieben werden, die eine ungültige Vertrauensbeziehung umfasst.
Vorzugsweise werden die Vertrauensbeziehung und/oder die Daten über die Vertrauensbeziehung ausgewählt oder eingegeben, nachdem die Verbundfunktionalität ausgewählt wurde, da dann eine geeignetere Zuordnung von bestimmten Funktionen zu bestimmten Vertrauensbeziehungen, d. h. eine geeignetere Zuordnung von bestimmten Auswahlmöglichkeiten an Optionen in Bezug auf die vertrauensbezogene Verarbeitung, vorgenommen werden kann. Beispielsweise können bestimmte Arten von Token Anforderungen an die Verschlüsselung von Signaturen stellen, die an Instanzen des Token-Typs erzeugt werden sollen.
Nachdem die Herstellung der Verbundbeziehung am Verbundpartner "X" eingeleitet worden ist, wird eine Vorlagendatei zur Herstellung einer Verbundbeziehung dynamisch erzeugt (Schritt 1414); die Vorlagendatei wird entsprechend den Daten aufgebaut, die von dem Verbundpartner erfasst werden müssen, wie vorstehend mit Bezug auf 13C erörtert wurde. Anschließend wird die Vorlagendatei an den Verbundpartner "Y" übertragen (Schritt 1416), der die empfangene Vorlagendatei so ändert, dass sie die benötigten partnerspezifischen Daten enthält, und dann schickt er die geänderte Vorlagendatei an den Verbundpartner "X" zurück (Schritt 1416). Nachdem die geänderte Vorlagendatei empfangen wurde (Schritt 1418), werden die angeforderten partnerspezifischen Daten entnommen (Schritt 1420) und am Verbundpartner "X" zur Verwendung bei nachfolgenden Verbundtransaktionen gespeichert (Schritt 1422), wodurch der Prozess beendet wird.
Es sei angemerkt, dass die Vorlagendatei (oder eine zweite Datei) partnerspezifische Daten über den Partner "X" enthalten kann, die an den Partner "Y" gesendet werden; wenn die Voralgendatei mit den Daten über den Verbundpartner "X" an den Verbundpartner "Y" gesendet wird, werden diese Daten in die Datenverarbeitungsumgebung des Verbundpartners "Y" importiert, um die Verbundbeziehung am Verbundpartner "Y" zu konfigurieren; der Import von Daten über den Verbundpartner "X" in der Datenverarbeitungsumgebung des Verbundpartners "Y" kann automatisch vorgenommen werden, so dass ein als Administrator tätiger Benutzer am Partner "Y" die Daten für die Verbundbeziehung nicht manuell konfigurieren muss.
Statt eine zuvor hergestellte Vertrauensbeziehung auszuwählen, kann die Vertrauensbeziehung in noch einer anderen alternativen Ausführungsform auch während des Aufbaus der Verbundbeziehung aufgebaut werden, wobei möglicherweise Funktionen in der Konsolenanwendung zur Verwaltung von Vertrauensbeziehungen, die in 11 gezeigt ist, zusammen mit der Konsolenanwendung zur Verwaltung von Verbundbeziehungen, die in 13A gezeigt ist, verwendet werden. Alternativ dazu kann die Konsolenanwendung zur Verwaltung von Verbundbeziehungen auch Funktionen zur Eingabe von vertrauenswürdigen Daten von einem als Administrator tätigen Benutzer oder zum Abruf von vertrauenswürdigen Daten aus einem geeigneten Datenspeicher, wie zum Beispiel einem Schlüsselspeicher, enthalten. In diesem Fall gibt der als Administrator tätige Benutzer auch Daten ein oder wählt Daten aus, um eine Vertrauensbeziehung aufzubauen, auf die sich die Verbundbeziehung gründen wird, z. B. indem er eine Auswahl unter mehreren privaten Schlüsseln oder mehreren Zertifikaten trifft oder diese eingibt. Das Unternehmen des als Administrator tätigen Benutzers, z. B. des Partners "X", kann diese vertrauenswürdigen Daten, z. B. ein Zertifikat mit öffentlichem Schlüssel, zu einer Vorlagendatei oder einer Begleitdatei hinzufügen, die an den Verbundpartner übertragen wird. Ebenso kann die geänderte Vorlagendatei, die von dem Verbundpartner empfangen wird, zusätzlich zu den partnerspezifischen Daten zum Aufbau einer Verbundbeziehung über partnerspezifische Daten verfügen, um eine Vertrauensbeziehung aufzubauen. Die Daten über die Vertrauensbeziehung würden der empfangenen Datei ebenfalls zusammen mit den Daten über die Verbundbeziehung entnommen werden, und die entnommenen Daten über die Vertrauensbeziehung würden in einer bestimmten Weise den Konfigurationsdaten für die Verbundbeziehung zugeordnet werden. Es sei auch angemerkt, dass der als Administrator tätige Benutzer alle oder die verbleibenden Daten über die Vertrauensbeziehung und/oder Daten über die Verbundbeziehung von einer oder mehreren anderen Quellen abrufen und diese Daten dann über die Konsolenanwendung zur Verwaltung von Verbundbeziehungen eingeben kann, um die gewünschte Vertrauensbeziehung oder die gewünschte Verbundbeziehung zu konfigurieren.
Es sollte daher nicht unerwähnt bleiben, dass eine Vertrauensbeziehung in zwei Phasen aufgebaut wird. In einer ersten Phase erfasst ein als Administrator tätiger Benutzer alle vertrauenswürdigen Daten für den Partner "X", beispielsweise seine privaten Schlüssel, die verwendet werden, um Daten beispielsweise durch Verschlüsselung und/oder digitale Signaturen sicher zu machen, die an den Verbundpartner "Y" und/oder seine anderen Verbundpartner gesendet werden. Wenn der Verbundpartner "X" nur über einen Satz von kryptografischen Schlüsseln verfügt, steht dem als Administrator tätigen Benutzer am Verbundpartner "X" möglicherweise keine Vertrauensbeziehung zur Auswahl, aber der als Administrator tätige Benutzer hätte die Möglichkeit, bei der Konfiguration der Verbundbeziehung neue Schlüssel hinzuzufügen, so dass der als Administrator tätige Benutzer auch eine neue Vertrauensbeziehung konfigurieren könnte.
In einer zweiten Phase werden die gesamten vertrauenswürdigen Daten für den Verbundpartner "Y" erfasst, zum Beispiel öffentliche Schlüssel und/oder digitale Zertifikate, die zur Prüfung der Gültigkeit beziehungsweise der Richtigkeit der Daten verwendet werden, die vom Verbundpartner "Y" empfangen werden. Wenn der Verbundpartner "X" diese Daten über den Verbundpartner "Y" bereits gespeichert hat, könnte der als Administrator tätige Benutzer diese Daten verwenden; dem als Administrator tätigen Benutzer kann eine Liste mit kryptografischen Schlüsseln usw. übergeben werden, während er über eine Verwaltungs-Konsolenanwendung eine Vertrauensbeziehung konfiguriert. Wenn der Verbundpartner "X" diese Daten über den Verbundpartner "Y" noch nicht gespeichert hat, ist es dem als Administrator tätigen Benutzer am Partner "X" freigestellt, diese vertrauenswürdigen Daten, wie zum Beispiel neue Schlüssel, mittels der Verwaltungs-Konsolenanwendung zur Laufzeit hinzuzufügen. Wie vorstehend erwähnt wurde, könnte sich der als Administrator tätige Benutzer am Verbundpartner "X" alternativ dazu dafür entscheiden, die vertrauenswürdigen Daten für den Verbundpartner "Y" über eine partnerspezifische Konfigurationsdatei zu importieren, woraufhin die entsprechende Anwendung am Verbundpartner "X" die vertrauenswürdigen Daten über den Verbundpartner "Y" in einem Datenspeicher am Verbundpartner "X" automatisch aktualisieren und dadurch eine Vertrauensbeziehung zwischen den beiden Verbundpartnern herstellen würde.
Spezialisierung der Unterstützung für eine Verbundbeziehung
Wie vorstehend erörtert wurde, müssen Unternehmen, wenn sie Maßnahmen zur Unterstützung von Geschäftsbeziehungen im Verbund ergreifen, den Benutzer eine Erfahrung machen lassen, in der sich die wachsende Zusammenarbeit zwischen zwei Unternehmen widerspiegelt. Insbesondere bedeutet dies, dass ein Benutzer seine Identität gegenüber einer Partei (die die Funktion eines Identitätsanbieters hat) nachweisen und sich dann einmalig bei einem Geschäftspartner im Verbund anmelden kann. Als Teil dieser Einmalanmeldung muss auch eine zusätzliche Funktionalität zur Lebenszyklusverwaltung des Benutzers im Verbund (FULM) wie zum Beispiel die Verknüpfung von Konten/die Aufhebung dieser Verknüpfung und die Einmalabmeldung unterstützt werden. Durch die Unterstützung dieser erweiterten Funktionalität bedingte Änderungen an der Infrastruktur bei beiden Parteien müssen so gering wie möglich gehalten werden. In der folgenden Erörterung wird mit dem Begriff "Partner" gewöhnlich ein Anforderer beschrieben, da diese Anforderer üblicherweise langfristige Beziehungen mit dem Identitätsanbieter haben. Diese Begriffe sind in diesem Abschnitt als austauschbare Begriffe zu betrachten.
Moderne Umgebungen haben diese Probleme gelöst, indem sie nur eine Einmalanmeldung unter Verwendung von anwendereigenen Protokollen oder unter Verwendung eines hausinternen Protokolls vorsehen, das mit eng aneinander gebundenen Parteien verwendet wird. Diese Lösungen nach dem Stand der Technik sind jedoch weder skalierbar, noch lassen sie eine "lose verbundene" Umgebung zu, eine Umgebung, in der neue Partner mit großen Datenverarbeitungsumgebungen problemlos in den Verbund aufgenommen (oder alte Partner aus dem Verbund entfernt) werden können, ohne auf Seiten des Diensteanbieters oder auf Seiten des Identitätsanbieters Änderungen an der Verbundumgebung vornehmen zu müssen. Zusätzlich zu einer Lösung, die als Teil der dynamischen Beschaffenheit einer lose verbundenen Umgebung eine angemessene Skalierung ermöglicht, müssen FULM-Lösungen unterstützt werden, bei denen dieselbe Funktionalität verschiedenen Parteien so zur Verfügung gestellt wird, dass es zu keiner Überlappung der Verarbeitung kommt. Das heißt, eine Umgebung vom Typ "Chinesische Mauer" kann installiert werden, wenn diese von einem neuen oder von einem vorhandenen Partner oder Anforderer benötigt wird, so dass die Installation eines jeden Partners gegen Änderungen, die an einer anderen Installation vorgenommen werden, abgeschirmt ist. Auf diese Weise wirken sich Änderungen, die am Profil eines Partners vorgenommen werden, nicht auf andere Partner auf.
Bei den derzeitigen Vorgehensweisen zur Anmeldung (zum Beispiel) werden alle Anmeldeanforderungen an eine einzige URI zur Verarbeitung gesendet. Dies Vorgehensweise ist in einer Umgebung angemessen, in der die Anmeldung von Benutzern auf einer direkten Identitätsprüfung beruht, das heißt, der Benutzer übergibt seine Anmeldedaten, und diese Anmeldedaten werden direkt ausgewertet. Erste Szenarien mit einer domänenübergreifenden Einmalanmeldung (cross domain single sign-on (cd-sso)) gingen nur von einer einzigen sich auf die Vertrauenswürdigkeit verlassenden Domäne mit einer bestimmten Heimdomäne aus beziehungsweise ließen diese zu. Wollte man mehreren sich auf die Vertrauenswürdigkeit verlassenden Domänen Rechnung tragen, setzte dies voraus, dass jede sich auf die Vertrauenswürdigkeit verlassende Domäne über eine eigene cd-sso-URL in der Heimdomäne verfügt, so dass zwei sich auf die Vertrauenswürdigkeit verlassende Domänen, ARelyA.com und BRelyB.com, ihre Benutzer an eine ganz bestimmte URL verweisen würden. Jede URL sieht sich einer ganz bestimmten Instanz der cd-sso-Funktionalität gegenüber, wobei jede Instanz mit den Daten konfiguriert wird, die für die cd-sso-Erfahrung dieser sich auf die Vertrauenswürdigkeit verlassenden Domäne benötigt werden. Zusätzlich zu diesen Daten auf Konfigurationsebene können sich diese beiden URLs auch unabhängigen Ausführungen der cd-sso-Funktionalität wie zum Beispiel einem Protokoll vom Typ Liberty ID-FF 1.1 Browser/Artifact SSO im Vergleich zu einem Protokoll vom Typ SAML 1.0 Browser/Artifact SSO gegenübersehen.
Diese Vorgehensweise ist in den Fällen nicht so optimal, in denen beispielsweise alle diese Parameter den Endpunkt der sich auf die Vertrauenswürdigkeit verlassenden Domäne an demselben Speicherort ablegen – jeder Parameter muss für jeden Endpunkt einer Heimdomäne einzeln verwaltet werden. Diese Herangehensweise ist auch in Szenarien weniger geeignet, in denen ein Benutzer eine Identitätsbestätigung übergibt, die den Nachweis der Identität durch eine andere Partei erbringt. In diesem Szenario möchten zwei Geschäftspartner vielleicht verschiedene URLs für dieselbe Funktionalität verwenden. Eine Basis-URL, www.servicesRus.com, die die URL www.servicesRus.com/partnerAlogin für den Partner A und die URL www.servicesRus.com/partnerBlogin für den Partner B verwendet, ermöglicht beispielsweise dem PartnerA und dem PartnerB die Verwendung von verschiedenen Endpunkten, um auf dieselbe Funktionalität zuzugreifen (PartnerLogin).
Bei dem in diesem Abschnitt beschriebenen erfindungsgemäßen Verfahren können sich mehrere URLs derselben Funktionalität gegenübersehen, wodurch die Notwendigkeit für einen Identitätsanbieter entfällt, mehrere einzelne Systeme installieren und konfigurieren zu müssen, um dieselbe Verbundfunktionalität zu erreichen. Diese Erfindung ermöglicht es dem Identitätsanbieter vorzugsweise auch, bei einem Partner einen problemlosen Wechsel zu einem neuen Protokoll vorzunehmen (z. B. von Liberty 1.1 zu WS-Federation), ohne dass dies Auswirkungen auf die Dienste hätte, die anderen Partnern in dem Verbund zur Verfügung stehen. Bei dem in diesem Abschnitt beschriebenen Verfahren ist es auch möglich, die Profilkonfiguration an den betreffenden Partner zu binden, so dass dieselbe Laufzeit, ungeachtet dessen, ob eine oder mehrere URLs darauf zugreifen können, mit verschiedenen (Laufzeit-)Konfigurationsparametern auf dynamische Weise individuell festgelegt werden kann.
Vorzugsweise ermöglicht diese Erfindung die zentrale Konfiguration und die zentrale Verwaltung von mehreren Instanzen derselben Funktionalität, auf die jedoch verteilt zugegriffen werden kann. Betrachten wir beispielsweise ein Einmalanmeldeprofil, auf das mehrere Partner zugreifen. Dieses Profil kann am Endpunkt www.servicesRus.com/ssoprofile zur Verfügung stehen. Wenn dieses Profil eine einzige Konfiguration, eine einzige Instanziierung und einen einzigen Endpunkt aufweist, müssen alle Parteien, die auf diesen Endpunkt zugreifen, dieselben Anforderungen an Endpunkte, Parameter und die Konfiguration stellen, und sie müssen gemeinsame Endpunkte zulassen. Indem sie Konfigurationsdaten als Laufzeitdaten behandelt und diese Daten der entsprechenden FULM-Laufzeitanwendung übergibt, wenn diese aufgerufen wird, ermöglicht die Erfindung vorzugsweise, dass Instanzen der entsprechenden FULM-Anwendung erzeugt werden.
Gemäß einer Ausführungsform der vorliegenden Erfindung wird ein Satz von "globalen" Konfigurationsdaten für die FULM-Anwendung festgelegt. Diese globalen Daten legen die Standardparameter fest, die für die Konfiguration einer Beziehung angeboten werden. Parameter wie die Lebensdauer einer Anforderung beispielsweise können als Teil der Konfiguration der FULM-Anwendung selbst festgelegt werden. Bei der Konfiguration einer Verbundbeziehung wird dieser Wert als der Standardwert übergeben, der auf den Verbund angewendet werden soll. Dieser Wert kann dann für jeden einzelnen Verbund als Teil der Konfiguration dieser Verbundbeziehung individuell festgelegt werden.
Überdies ist die Verbundbeziehung gemäß einer Ausführungsform der Erfindung zum Zeitpunkt der Festlegung einer Verbundbeziehung an die "Anbieterseite" gebunden (wobei der Anbieter die Partei ist, die das Produkt installiert). Diese Beziehung wird von einem Satz von Konfigurationsparametern festgelegt, die an die Beziehung gebunden sind. Zu diesen Konfigurationsparametern gehört der jeweilige Endpunkt, der anbieterseitig verwendet wird, zum Beispiel ein Endpunkt, der für alle Partner verwendet wird, so dass die URL, die von allen serviceRus-Partnern des Anbieters für SSO-Zwecke verwendet wird, als www.servicesRus.com/allpartners festgelegt wird. Bestimmte Parameter wie die Lebensdauer einer Anforderung (zum Beispiel) könnten als "globale" Parameter behandelt werden, die für alle Verbundbeziehungen gelten, für die ein bestimmter Identitätsanbieter zuständig ist. Bei dieser Erfindung ist es möglich, globale Parameter (die von der Anwendung als Standardwerte bereitgestellt werden, wenn eine Verbundbeziehung konfiguriert wird) individuell für die Verbundbeziehung festzulegen. Bei der Konfiguration einer Beziehung können folglich Parameter wie die Lebensdauer einer Anforderung den Wert haben, der den festgelegten (Standard-)Werten einer Anwendung entspricht, oder den Wert, der als Teil der Konfiguration der Beziehung individuell festgelegt wurde.
Eine Beziehung ist erst vollständig definiert, wenn Partner der Verbundbeziehung hinzugefügt worden ist. Wenn Partner der Beziehung hinzugefügt werden, müssen partnerspezifische Daten festgelegt werden (zum Beispiel die URL des Dienstes, an die der Anbieter SSO-Antworten schickt). Diese partnerspezifischen Konfigurationsdaten können auch eine weitere individuelle Festlegung von Parametern wie zum Beispiel der Lebensdauer einer Anforderung (deren für die FULM-Anwendung konfigurierter Standardwert möglicherweise wiederum für die Verbundbeziehung in einen individuellen Wert abgeändert wurde) beinhalten.
Wenn zwei Partner, A und B, auf der Seite des Identitätsanbieters unterschiedliche Parameter erfordern, beispielsweise, weil ein Partner nur ungern Daten mit dem anderen Partner gemeinsam nutzt, können diese Partner als zwei getrennte Beziehungen konfiguriert werden (www.servicesRus.com/partnerA gegenüber www.servicesRus.com/partnerB). In beiden Fällen sind die erforderlichen Konfigurationsdaten an die Verbundbeziehung gebunden. Wenn eine URI, die dieser Funktionalität entspricht, aufgerufen wird, werden die entsprechenden Konfigurationsdaten abgerufen und im Rahmen der Protokollausführung verwendet. Gemäß einer bevorzugten Ausführungsform der Erfindung ist der Partnername in einer bestimmten Verbundbeziehung eindeutig und kann folglich zum Abruf der Laufzeit-Parameter verwendet werden, doch erkennt der Fachmann, dass die bei einer bestimmten Anforderung zu verwendenden Laufzeit-Parameter auch mit anderen Mitteln festgestellt werden könnten. Folglich kann dieselbe Protokoll-Laufzeit zur Einmalanmeldung (SSO) von verschiedenen Partnern auf der Grundlage der für den jeweiligen Partner festgelegten Parameter genutzt werden.
Bei dieser Erfindung werden vorzugsweise zum Zeitpunkt des Aufrufs und der Instanziierung einer Protokoll-Laufzeit, beispielsweise einer SSO-Laufzeit, die für diese Laufzeit benötigten Parameter dynamisch empfangen. Das heißt, jedes Mal, wenn die Protokoll-Laufzeit aufgerufen wird, wird sie mit den Laufzeit-Parametern instanziiert, die ihr dynamisch übergeben wurden. Diese Instanziierung kann stattfinden, wenn die FULM-Anwendung gestartet wird, wodurch alle konfigurierten Einschübe hochgefahren werden, wenn ein neuer Partner am Identitätsanbieter konfiguriert wird oder auf Anforderung eines Partners. Der Fall der Anforderung durch einen Partner könnte stattfinden, wenn die erste Anforderung von einem bestimmten Partner gestellt wird oder wenn die bereits initialisierten Instanzen ihre Spitzenauslastung erreicht haben. Eine weitere Möglichkeit, ein Kapazitätsproblem anzugehen, besteht darin, eine weitere Kopie der FULM-Anwendung selbst zusammen mit all ihren Instanzen zu replizieren. Die Kontaktstelle überwacht die Weiterleitung der Partner-Anforderungen an die entsprechende Instanz der entsprechenden Kopie der FULM-Anwendung.
Wie in 15 gezeigt ist, verwenden der Partner A und der Partner B dieselbe URL sowie dieselben anbieterseitigen Konfigurationsdaten, wenn sie über den Kontaktserver 1505 die Verbundanforderungen 1501, 1503 für eine bestimmte Protokoll-Laufzeit, ein Zusatzprogramm 1507 zur FULM-Anwendung 1509, stellen. In der Figur wie auch anderswo in der Beschreibung ist ein Zusatzprogramm 1507 zur Haupt-FULM-Anwendung 1509 eine bevorzugte Laufzeit-Anwendung, wobei der Fachmann jedoch versteht, dass in anderen Ausführungsformen der Erfindung andere Laufzeiten verwendet werden könnten. Instanzen eines bestimmten Protokoll-Zusatzprogramms, von denen jede die abgerufenen Laufzeitdaten verwendet, sind in der Figur ebenfalls dargestellt. Anders ausgedrückt, dies sind Instanzen desselben Protokoll-Zusatzprogramms. Die FULM-Anwendung der vorliegenden Erfindung kann vorzugsweise jedoch über Zusatzprogramme unterschiedlicher Beschaffenheit verfügen, das heißt, jedes Zusatzprogramm führt ein bestimmtes Protokoll aus. Folglich könnten einzelne Laufzeiten, die verschiedene SSO-Protokolle verwenden, z. B. WS-Federation oder Liberty 1.1, der FULM-Anwendung zugeordnet werden, wobei jede Laufzeit Instanzen erzeugt, wenn eine Anforderung eines Partners/Anforderers dies verlangt. Wenn einer dieser Partner eine Instanz dieser Laufzeit 1507 aufruft, werden die (gemeinsamen) anbieterseitigen Daten und die partnerspezifischen Daten als Parameter des Protokollaufrufs verwendet, um eine entsprechende Instanz der Laufzeit zu erzeugen. Wie in 15 gezeigt ist, kann der Partner C eine Anforderung 1511 unter Verwendung von anderen anbieterseitigen Konfigurationsdaten stellen (zum Beispiel unter Verwendung einer anderen Aufruf-URL), um eine Instanz desselben Protokoll-Zusatzprogramms 1507 aufzurufen; wenn der Partner C dieses Protokoll-Zusatzprogramm 1507 aufruft, werden die anbieter- und die partnerspezifischen Daten des Partners C dynamisch als Parameter in die Anforderung aufgenommen. Darüber hinaus kann dasselbe Protokoll mehr als einmal instanziiert werden, so dass der Partner D seine eigene Instanz des (vollkommen hinter einer "Chinesischen Mauer" geschützten) Protokoll-Zusatzprogramms 1513 mit seinen anbieter- und partnerspezifischen Daten aufrufen kann.
Als ein Schritt, der vor dem Aufruf der Laufzeit durchgeführt wird, bindet die FULM-Anwendung die Verwaltung eines Konfigurationsprozesses ein, um die Partner- und anbieterspezifischen Daten sowie die globalen Daten festzulegen, die für jeden vom Identitätsanbieter instanziierten Verbundprozess verwendet werden. In der bevorzugten Ausführungsform werden diese konfigurierten Daten zur Laufzeit abgerufen und dem entsprechenden Protokollzusatzprogramm übergeben. Dadurch kann eine einzige FULM-Anwendung mehrere Instanzen eines Verbundprozesses skalierbar ausführen, wobei jede Instanz über ihren eigenen Satz von Konfigurationsdaten verfügt.
Statt alle Parameter an Endpunkte zu binden, ermöglicht die Erfindung vorzugsweise, dass einige "globale" Parameter gesetzt werden können; andere Parameter werden dann nach Bedarf individuell festgelegt. Wenn es die Heimdomäne des Identitätsanbieters beispielsweise erforderlich macht, dass alle SSO-Anforderungen signiert werden und eine auf der Aktualität beruhende Lebensdauer von 2 Sekunden haben, dürfte es nicht notwendig sein, diese Daten für jeden Endpunkt oder für jeden Partner zu konfigurieren. Diese Daten können als "globale" Daten betrachtet werden, die auf die Heimdomäne anwendbar sind und auf alle SSO-Endpunkte angewendet werden, die die Heimdomäne anzeigt.

In der unten stehenden Tabelle sind bestimmte Parameter für eine Gruppe von Diensteanbietern, ArelyA.com, BrelyB.com, CrelyC.com und DrelyD.com, angegeben. Der Fachmann versteht, dass diese Parameter lediglich Beispielcharakter haben und dass im Rahmen der Wesensart der Erfindung andere Parameter konfiguriert werden könnten. Die Diensteanbieter A und B müssen als Teil ihrer SSO-Anforderung Zufallszahlen (nonces) bereitstellen. In diesem Beispiel greifen alle Anbieter A, B und C auf SSO-Dienste in der Heimdomäne zu, deren erste URL homedomain/ABC_SSO.html ist, und der Anbieter D greift auf SSO-Dienste in der Heimdomäne zu, deren erste URL homedomain/D_SSO.html ist.

Parameter	ArelyA	BrelyB	CrelyC	DrelyD
Signierte Anforderung	Y	Y	Y	Y
2-Sekunden-Aktualisierung	Y	Y	Y	Y
Zufallszahl (nonce)	Y	Y	N	N
Lokaler Endpunkt	ABC_SSO.html	ABC_SSO.html	ABC_SSO.html	D_SSO.html
SP-Endpunkt	A_ssoResp.html	B_ssoResp.html	C_ssoResp.html	D_ssoResp.html

Daraus folgt also, dass die Partner A, B und C alle so konfiguriert werden können, dass sie eine einzige Beziehung bilden (z. B. providerToABC), und der Partner D wird so konfiguriert, dass er seine eigene Beziehung bildet (z. B. providerToD). Die ersten beiden Parameter, die signierte Anforderung und die 2-Sekunden-Aktualisierung, sind "globale" Parameter, die von der Heimdomäne aller Diensteanbieter benötigt werden. Sie können auf der Ebene des Identitätsanbieters als Teil der Konfiguration der FULM-Anwendung konfiguriert und auf alle SSO-Anforderungen angewendet werden.
Der dritte Parameter (die Zufallszahl (nonce)), wird auf A und B oder global auf alle Diensteanbieter angewendet, die über ABC_SSO.html EXCEPT C auf cd-sso-Dienste zugreifen. Dieser Parameter kann auf der Stufe der cd-sso-URL angewendet und dann für den Partner C zur Laufzeit individuell festgelegt (überschrieben) werden. Man rufe sich ins Gedächtnis zurück, dass der Partner D über eine andere URL auf die Verbunddienste zugreift. Unter der Annahme, dass der Zufallszahl-(nonce-)Parameter auf der URL-Stufe konfiguriert wird, braucht dieser für den Anbieter D nicht überschrieben zu werden, da er für den Anbieter D einfach nicht konfiguriert wird.
Da die mit der Verarbeitung einer SSO-Anforderung (ungeachtet des Endpunkts) verbundenen Daten als Laufzeitdaten abgerufen werden, können alle Anbieter A, B und C auf die einzelne SSO-URL (ABC_SSO.html) zugreifen. Wenn eine an den Identitätsanbieter gerichtete Anforderung an dieser URL eintrifft, wird die Anforderung geprüft, um die Quelle (A, B oder C) festzustellen. Auf der Grundlage der Identität des Anforderers werden die zugehörigen Konfigurationsparameter abgerufen (zur Laufzeit) und als Teil der Gültigkeitsprüfung der Anforderung verwendet.
In einer bevorzugten Ausführungsform der vorliegenden Erfindung werden die Konfigurationsdaten in 3 Stufen erfasst, was auch nachstehend wesentlich ausführlicher beschrieben wird:

1. Erfasse global angegebene Daten, d. h. Daten, die auf der Ebene des Identitätsanbieters angegeben sind (z. B. Erzeugen einer Signatur, Aktualität).
2. Erfasse verbundspezifische anbieterseitige Endpunkt-Daten (z. B. URLs, Verwendung von Zufallszahlen (nonces), und lege bei Bedarf globale, vom Anbieter auf Standardwerte gesetzte Konfigurationsdaten für den Verbund individuell fest (z. B. Überschreiben der Signatur).
3. Erfasse anfordererspezifische Daten (z. B. partnerseitige URLs) und überschreibe bei Bedarf verbundspezifische oder auf einen Standardwert gesetzte Konfigurationsdaten (z. B. Überschreiben der Zufallszahl (nonce).

Ein Vorteil dieser Ausführungsform besteht darin, dass sie die an jedem Punkt verwalteten Datenmenge auf ein Mindestmaß verringert. Die Erfindung macht es vorzugsweise auch leicht oder überhaupt möglich, globale Parameter in einem einzigen Schritt zu ändern, sie in einem einzigen Schritt für eine Abstufung zu überschreiben, die von einem Unternehmen oder einem Administrator gewünscht wird.
Globale Daten werden auf der Verwaltungsebene der Gesamtkonfiguration des Identitätsanbieters verwaltet. Endpunktspezifische Daten (die sich in diesem Fall auf die Endpunkte des Identitätsanbieters beziehen, z. B. im vorstehenden Beispiel homedomain/ABC_cdsso.html), werden auf der Ebene der Endpunkt-Konfiguration verwaltet, d. h. ein "Verbund" – eine Geschäftsbeziehung zwischen einem Anbieter und einem oder mehreren Partnern – wird festgelegt. Anfordererspezifische Daten (auch als partnerspezifische Daten bezeichnet) werden auf der Ebene der Partnerverwaltung verwaltet.
Manche Daten werden immer auf der Ebene des Partners/Anforderers verwaltet wie zum Beispiel die öffentlichen Signatur- und Verschlüsselungsschlüssel dieses Partners, mit denen der Identitätsanbieter signierte Anforderungen, die er vom dem Partner empfangen hat, auf Gültigkeit prüfen kann. Es sei angemerkt, dass die Vorteile dieser Erfindung vorzugsweise selbst dann nicht verloren gehen, wenn jeder Partner mit einem eigenen Endpunkt am Identitätsanbieter endet, da die globalen Konfigurationsdaten immer noch auf alle Endpunkte angewendet werden.
Nun Bezug nehmend auf die 16A bis 16D wird der Konfigurationsprozess für die verbundbezogenen Parameter beschrieben. Der Prozess beginnt mit dem Schritt 1601, in dem die geschäftlichen und rechtlichen Beziehungen zwischen dem Identitätsanbieter und den Diensteanbietern hergestellt werden. Bisher war dieser Prozess größtenteils ein manueller Prozess, da er zunehmend jedoch mit elektronischen Vereinbarungen abgewickelt wird, die z. B. in XML für elektronische Geschäftsprozesse (ebXML) geschrieben werden, wird der Prozess mehr und mehr automatisiert. Im Schritt 1603 beginnt die Konfiguration der Parameter für die Verbundbeziehung. Als Erstes wird im Schritt 1605 der Verbundname festgelegt. In einer bevorzugten Ausführungsform besteht dieser Schritt aus der Festlegung einer Basis-URL für den Identitätsanbieter, von der viele andere URLs automatisch abgeleitet werden können. Das Überschreiben der automatisch abgeleiteten URLs durch den Benutzer ist eine optionale Ausführungsform der Erfindung.
Im Schritt 1607 gibt der Benutzer an, ob er die Parameter für den Identitätsanbieter oder für den Diensteanbieter (oder für beide) konfiguriert. Im Schritt 1609 werden die Kontaktdaten für den Identitätsanbieter und den Diensteanbieter, gewöhnlich URLs, eingegeben. Als Nächstes werden im Schritt 1611 die gewünschten Verbunddienste und Protokolle ausgewählt, die bei der Verbundbeziehung verwendet werden. Zu den Verbunddiensten kann zum Beispiel die Identitätsprüfung von Benutzern, die Annahme von Identitätsbestätigungen oder die Umsetzung von Bestätigungen gehören. Zu auswählbaren Protokollen gehören von Liberty, WS-Federation oder SAML (OASIS) veröffentlichte Protokolle zur Einmalanmeldung. Als Nächstes werden im Schritt 1613 die Einmalanmeldedaten konfiguriert, was nachstehend ausführlicher beschrieben wird. Wie in den vorstehenden Abschnitten beschrieben wurde, werden die vertrauenswürdigen Daten für den Verbund im Schritt 1615 konfiguriert. Dieser Prozess endet im Schritt 1617.
16B zeigt die Konfiguration der Einmalanmeldedaten ausführlicher. Der Schritt 1621 startet diesen Prozess. Im Schritt 1623 wird das Protokoll für die Einmalanmeldung, z. B. WS-Federation, Liberty 1.1 oder SAML, ausgewählt. Wenn WS-Federation ausgewählt wird, Schritt 1625, wird es entsprechend den Parametern und Auswahlmöglichkeiten für die Parameter, die in dem Protokoll zur Verfügung stehen, konfiguriert, Schritt 1627. Wenn Liberty 1.1 ausgewählt wird, Schritt 1629, wird die Konfiguration entsprechend den Parametern und Auswahlmöglichkeiten für die Parameter, die in dem Protokoll zur Verfügung stehen, fortgesetzt, Schritt 1631. Wenn SAML ausgewählt wird, Schritt 1633, wird die Einmalanmeldung entsprechend den Parametern und Auswahlmöglichkeiten für die Parameter, die in dem Protokoll zur Verfügung stehen, konfiguriert, Schritt 1635. Der Prozess endet im Schritt 1637.
Die 16C und 16D zeigen die Konfiguration für das Protokoll Liberty 1.1 ausführlicher. Der Fachmann versteht, dass ganz ähnliche Schritte für die Protokolle WS-Federation oder SAML mit den erforderlichen Unterschieden durchgeführt würden, um den Unterschieden in den jeweiligen Protokollen Rechnung zu tragen.
Die "eigene" Seite der Konfiguration von Liberty beginnt mit dem Schritt 1651. Als Nächstes wird im Schritt 1653 das betreffende Profil, Liberty, Browser POST, Browser Artifact oder Liberty-enabled Clients or Proxies (LECP), ausgewählt. Die Entscheidung im Schritt 1655 legt fest, ob eine von der Anwendung festgelegte Basis-URL, z. B. www.idp.com/webseal, verwendet werden soll. Wenn nicht, Schritt 1657, wird eine verbundweite Basis-URL, z. B. www.idp.com/webseal/federation federationABC, festgelegt. Diese Basis-URL gibt die Daten an, von denen alle Endpunkte der Verbundanbieterseite festgelegt werden. In diesem Szenario ist die von der Anwendung festgelegte Basis-URL (www.idp.com/webseal) ein globaler Konfigurationsparameter, der zu dem Zeitpunkt, zu dem die Anbieterseite (die "eigene" Seite) der Verbundbeziehung konfiguriert wird, individuell festgelegt werden kann (www.idp.com/webseal/federationABC).
Im Schritt 1659 stellt die Entscheidung fest, ob das Browser-Artefakt-Profil ausgewählt wurde. Wenn ja, wird das Browser-Artefakt im Schritt 1661 konfiguriert. Im Schritt 1663 wird festgestellt, ob es eine vom Verbund festgelegte SSO-URL gibt, wenn nicht, werden im Schritt 1665 verbundspezifische Endpunkte für jeden Partner individuell festgelegt. Im Schritt 1667 wird festgestellt, ob es von der Anwendung festgelegte Parameter für die Verbundbeziehung gibt, z. B. für die Zufallszahl (nonce), die Lebensdauer usw. Wenn nicht, werden im Schritt 1669 verbundspezifische Laufzeit-Parameter für die Beziehung individuell festgelegt. Im Schritt 1671 werden die Token-Daten konfiguriert, die zur Verwaltung der Vertrauensbeziehung mit dem Verbund verwendet werden. Im Schritt 1673 werden die Identitätsabbildungsdaten konfiguriert. Diese Daten dienen zur Festlegung, welche Transformationen und Abbildungen gegebenenfalls auf die in dem Token vorgegebenen Daten angewendet werden, das zwischen den Partnern ausgetauscht wird, wobei die Art des Token im Schritt 1671 ermittelt und angegeben wurde.
Wenn das Browser-Artefakt-Profil nicht ausgewählt wird, werden Tests 1675 und 1679 durchgeführt, um festzustellen, ob das POST-Profil oder das LECP-Profil des Browsers ausgewählt wurde. Wenn ja, werden die entsprechenden Konfigurationsschritte 1677, 1681 durchgeführt. Diese Konfigurationsschritte sind ähnlich den Konfigurationsschritten, die vorstehend in Bezug auf das POST-Profil des Browsers erörtert wurden.
Im Schritt 1683 ist die Konfiguration des SSO-Profils abgeschlossen, und die restlichen Schritte der Konfiguration, z. B. die Konfiguration der vertrauenswürdigen Daten, werden durchgeführt.
16D zeigt die Konfiguration der Partnerseite der Verbundbeziehung. Im Schritt 1687 beginnt der Prozess. Im Schritt 1689 werden die Endpunkte der Partnerseite in die von dem Partner festgelegte Verbundkonfiguration eingegeben. Im Schritt 1691 werden die partnerseitigen Vertrauensdaten, z. B. die vom Partner festgelegten Signaturschlüssel, in die Verbundkonfigurationsdatei eingegeben. Die Entscheidung im Schritt 1693 stellt fest, ob vom Verbund festgelegte Regeln bei der Identitätsabbildung angewendet werden sollen. Wenn nicht, Schritt 1695, wird die Identitätsabbildung individuell nach partnerspezifischen Regeln vorgenommen. Im Schritt 1697 werden die verbundspezifischen Laufzeit-Parameter für den Partner individuell festgelegt. Im Schritt 1699 wird der Partner in den Verbund aufgenommen.
Als Ergebnis dieses Prozesses werden die Konfigurationsparameter der Verbundbeziehung festgelegt und können mit Hilfe der XML-Formatierung (zum Beispiel) dauerhaft dargestellt werden. Zu diesen Konfigurationsdaten gehören alle Parameter, die erforderlich sind, um diese Verbundbeziehung uneingeschränkt festzulegen. Diese Daten können auf der Stufe der Verbundbeziehung oder auf einer feineren Stufe, wie zum Beispiel jeder paarweisen Zuordnung von Verbundpartnern, verwaltet werden. Wenn die Verwaltung auf der Stufe der gesamten Verbundbeziehung erfolgt, sind die Konfigurationsdaten für jeden Partner (und ihre partnerspezifischen Konfigurationsdaten) in der Gesamtkonfiguration enthalten. Wenn die Konfigurationsdaten für eine Verbundpartner-Beziehung zur Laufzeit benötigt werden, können diese (beispielsweise) von der Gesamtkonfiguration des Verbunds abgeleitet werden.
Im Anschluss an die Konfiguration wird der Endpunkt des Partners einem der Zusatzprogramme zugeordnet, um die die FULM-Anwendung erweitert wurde. Jeder Konfigurationsprozess legt eine einzelne "Kette" von Konfigurationswerten fest, die für eine Verbund/Partner-Beziehung gelten, d. h., die Standardwerte der FIM-Anwendungsebene werden individuell als verbundspezifische Standardwerte und als partnerspezifische Konfigurationswerte festgelegt. Diese Kette ist durch die Verknüpfung aus Verbundname und Partnername eindeutig gekennzeichnet (und ist somit eindeutig). Wenn eine Anforderung eintrifft, die mit einem bestimmten Verbund/Partner gekennzeichnet ist (man erinnere sich, dass Verbunde nur für ein einziges Protokoll festgelegt werden), wird die entsprechende Kette gefunden und zur Bereitstellung der Konfigurationswerte verwendet, die für die (verschiedenen) Funktionen der Zusatzprogramme notwendig sind.
In mindestens einer bevorzugten Ausführungsform nutzt jedes Zusatzprogramm eines der SSO-Protokolle (Liberty, WS-Federation usw.) zur Ausführung, so dass eine Möglichkeit der Auswahl darin bestünde, dass der Partner an das entsprechende Zusatzprogramm weitergeleitet würde. Eine Instanz dieses Zusatzprogramms wird dann (zumindest logisch) mit den Konfigurationsparametern aufgerufen, die für diese festgelegte Kombination aus Verbundbeziehung-Partner konfiguriert wurden.
Wenn die erforderliche Laufzeit aufgerufen wird (zum Beispiel ein WS-Federation-SSO-Protokoll), werden die Parameter, die diesen Verbund festlegen (z. B. Lebensdauer/Aktualität-Parameter, partnerseitige Endpunkt usw.), der Laufzeit als Laufzeit-Parameter übergeben.
Schlussfolgerung
Die Vorteile der vorliegenden Erfindung dürften in Anbetracht der vorstehenden ausführlichen Beschreibung offensichtlich sein. Bei einer Lösung nach dem Stand der Technik ermöglichen die Spezifikationen der Liberty Alliance einen Austausch von Metadaten durch XML-formatierte Dateien. Jedoch machen sie es nicht möglich, dass die angeforderten Metadaten dynamisch ermittelt werden, so dass nur relevante Daten von einem Verbundpartner angefordert werden.
Im Gegensatz dazu sieht die vorliegende Erfindung vorzugsweise eine leichter verwaltbare und skalierbare Lösung für die Konfiguration von Partnern in einer Datenverarbeitungs-Verbundumgebung vor. Idealerweise würde eine Umgebung vom Typ einer übertragenen Verwaltung verwendet werden, damit ein Partner seine Daten über eine Vertrauensbeziehung anbieterseitig verwalten könnte, wodurch die Administratoren des Anbieters von der Notwendigkeit oder Verantwortung befreit würden, Daten von einem Partner abzurufen; der Partner hätte eine begrenzte Kontrolle, um seine Daten in Bezug auf eine Verbundbeziehung durch die den Verbund unterstützenden Anwendungen in der Datenverarbeitungsumgebung des Anbieters zu verwalten.
Wenn es keine Lösungsansätze in Form einer übertragenen Verwaltung gibt, konfiguriert ein als Administrator tätiger Anbieter eine Verbundbeziehung. Die XML-formatierte Konfigurationsdatei oder Vorlage wird dann dynamisch gemäß den Eigenschaften der Verbundfunktionalität erzeugt, die zuvor für die Zuordnung zu der Verbundbeziehung ausgewählt wurde. Diese Konfigurationsdatei enthält leere oder unausgefüllte XML-Elemente für alle Daten, die von einem Verbundpartner benötigt werden, um den Partner in eine Verbundbeziehung aufzunehmen und zu konfigurieren. Diese Konfigurationsdatei wird in irgendeiner Weise, z. B. per eMail, auf Diskette, CD-ROM, per HTTP POST, SOAP usw., an den Verbundpartner gesendet.
Alternativ dazu werden mehrere Dateien/Vorlagen verwendet. Beispielsweise könnte eine Datei alle Daten enthalten, die an den Verbundpartner, z. B. den Partner "Y", über die Konfiguration des Verbundpartners übertragen werden müssen, der die Verbundbeziehung einleitet, z. B. den Partner "X", und in diese Datei würden die erwarteten Konfigurationsdaten eingegeben werden, so dass sie nicht geändert werden müsste, um Daten vom Partner "Y" zu erhalten. Die andere Datei könnte Platzhalter für alle Daten enthalten, die der Partner "X" über den Partner "Y" wissen muss; diese Datei enthält keine der notwendigen Konfigurationsdaten, so dass sie geändert werden muss, damit sie die notwendigen Konfigurationsdaten enthält, und anschließend muss sie an den Partner "X" zurückgeschickt werden.
Der Verbundpartner würde die benötigten Daten dann eingeben und die ausgefüllte Date an den Administrator des Anbieters zurücksenden. Diese geänderte Datei wird dann in die Verbundbeziehung importiert, wodurch die Partnerdaten für die Verbundpartnerschaft konfiguriert werden. Wenn der Partner nicht alle benötigten Daten bereitgestellt hat, könnte der Administrator des Anbieters veranlasst werden, einen Konfigurationsprozess zu durchlaufen, um die restlichen Daten zu konfigurieren, insbesondere unter Verwendung einer Anwendung mit grafischer Benutzeroberfläche, in die der Administrator die benötigten Daten eingibt.
Es sollte nicht unerwähnt bleiben, dass die vorliegende Erfindung zwar im Zusammenhang mit einem uneingeschränkt funktionierenden Datenverarbeitungssystem beschrieben wurde, der Fachmann aber versteht, dass die Prozesse der vorliegenden Erfindung in Form von Befehlen auf einem rechnerlesbaren Datenträger und in einer Vielzahl von anderen Formen vertrieben werden kann, und zwar ungeachtet der jeweiligen Art der Signal tragenden Medien, die tatsächlich zum Vertrieb verwendet werden. Zu Beispielen für rechnerlesbare Datenträger gehören Datenträger wie zum Beispiel ein EPROM, ein ROM, ein Band, Papier, eine Diskette, ein Festplattenlaufwerk, ein RAM und CD-ROMs sowie Übertragungsmedien wie zum Beispiel digitale und analoge Datenübertragungsverbindungen. Unter einem Verfahren versteht man im Allgemeinen eine selbstkonsistente Folge von Schritten, die zu einem gewünschten Ergebnis führen. Diese Schritte setzen die physische Verarbeitung von physikalischen Größen voraus. Gewöhnlich, aber nicht unbedingt, haben diese Größen die Form von elektrischen oder magnetischen Signalen, die gespeichert, übertragen, verknüpft, verglichen und in anderer Weise verarbeitet werden können. Es sollte nicht unerwähnt bleiben, dass die vorliegende Erfindung zwar im Zusammenhang mit einem uneingeschränkt funktionierenden Datenverarbeitungssystem beschrieben wurde, der Fachmann aber versteht, dass die Prozesse der vorliegenden Erfindung in Form von Befehlen auf einem rechnerlesbaren Datenträger und in einer Vielzahl von anderen Formen vertrieben werden kann, und zwar ungeachtet der jeweiligen Art der Signal tragenden Medien, die tatsächlich zum Vertrieb verwendet werden. Es sei jedoch angemerkt, dass all diese und ähnliche Begriffe den entsprechenden physikalischen Größen zuzuordnen sind und es sich dabei lediglich um praktische Bezeichnungen handelt, die auf diese Größen angewandt werden.
Die Beschreibung der vorliegenden Erfindung erfolgte zum Zweck der Veranschaulichung, und sie erhebt weder Anspruch auf Vollständigkeit, noch ist sie als auf die beschriebenen Ausführungsformen beschränkt zu verstehen. Der Fachmann erkennt, dass viele Ab- und Veränderungen möglich sind. Die Ausführungsformen wurden gewählt, um die Grundgedanken der Erfindung und ihre Anwendungen in der Praxis zu erklären und um anderen Fachleuten das Verständnis der Erfindung zu ermöglich, um verschiedene Ausführungsformen mit verschiedenen Änderungen zu realisieren, die anderen vorgesehenen Benutzern geeignet erscheinen mögen.

Claims

Verfahren zur Bereitstellung einer Verbundfunktionalität in einem Datenverarbeitungssystem, wobei das Verfahren Folgendes umfasst: Empfangen einer ersten Anforderung an einem ersten Datenverarbeitungssystem für Verbunddienste von einem Verbundanbieter, wobei die erste Anforderung von einem ersten Anforderer gestellt wird; Initialisieren einer Instanz einer Anwendung, um angeforderte Verbunddienste für den ersten Anforderer bereitzustellen, wobei die Instanz der Anwendung eine erste Laufzeit zur Folge hat, die gemäß Konfigurationsdaten einer Verbundbeziehung des ersten Anforderers mit dem Verbundanbieter individuell festgelegt wird, wobei die Konfigurationsdaten während der Initialisierung der Laufzeit dynamisch abgerufen werden; und Bereitstellen der angeforderten Verbunddienste mittels der individuell festgelegten Laufzeit.
Verfahren nach Anspruch 1, wobei der Verbundanbieter einer Vielzahl von Anforderern Verbunddienste bereitstellt, wobei das Verfahren des Weiteren Folgendes umfasst: Initialisieren einer Vielzahl von individuell festgelegten Laufzeiten, die gemäß Konfigurationsdaten der jeweiligen Verbundbeziehungen der Anforderer mit dem Verbundanbieter angeforderte Verbunddienste für die Anforderer bereitstellen, wobei die Konfigurationsdaten während der Initialisierung der Laufzeiten dynamisch abgerufen werden; und Bereitstellen der angeforderten Verbunddienste für jeden Anforderer, indem Anforderungen weitergeleitet werden, um eine individuell festgelegte Laufzeit entsprechend der Identität eines Anforderers und einer Verbundbeziehung zuzuteilen.
Verfahren nach Anspruch 2, wobei die erste individuell festgelegte Laufzeit auch einem zweiten Anforderer Verbunddienste bereitstellt und ebenfalls entsprechend den Konfigurationsdaten einer Verbundbeziehung des zweiten Anforderers mit dem Verbundanbieter initialisiert wird.
Verfahren nach Anspruch 2, wobei eine zweite individuell festgelegte Laufzeit einem dritten Anforderer Verbunddienste bereitstellt und entsprechend den Konfigurationsdaten einer Verbundbeziehung des dritten Anforderers mit dem Verbundanbieter initialisiert wird und wobei die Verbunddienste, die von der ersten und der zweiten individuell festgelegten Laufzeit bereitgestellt werden, weitgehend gleich sind.
Verfahren nach Anspruch 2, das des Weiteren Folgendes umfasst: Konfigurieren von Daten, die jede Verbundbeziehung zwischen dem Verbundanbieter und jedem der Vielzahl der Anforderer beschreiben.
Verfahren nach Anspruch 5, wobei der Schritt des Konfigurierens von Daten des Weiteren den Schritt des Konfigurierens von angegebenen globalen Daten umfasst, die allen Verbundbeziehungen mit der Ebene des Verbundanbieters gemeinsam sind.
Verfahren nach Anspruch 5, wobei der Schritt des Konfigurierens von Daten des Weiteren den Schritt des Konfigurierens von Daten einer Verbundbeziehung umfasst, die allein für die erste individuell festgelegte Laufzeit gelten.
Verfahren nach Anspruch 5, wobei der Schritt des Konfigurierens von Daten des Weiteren den Schritt des Konfigurierens von Daten umfasst, die speziell für den Anforderer gelten.
Verfahren nach Anspruch 7, wobei die globalen Standardkonfigurationsdaten des Verbundanbieters mit den konfigurierten Daten der Verbundbeziehung überschrieben werden.
Verfahren nach Anspruch 8, wobei die globalen Standardkonfigurationsdaten des Verbundanbieters oder die Daten der Verbundbeziehung mit den konfigurierten, speziell für den Anforderer geltenden Daten überschrieben werden.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der Verbundanbieter eine Identitätsanbieter ist, der Anmeldedaten für Anforderer verwaltet.
System, das einen Speicher und einen Prozessor enthält, um in einem Datenverarbeitungssystem eine Verbundfunktionalität bereitzustellen, wobei das System ein Mittel umfasst, um das Verfahren nach einem der Ansprüche 1 bis 11 durchzuführen.
Rechnerprogramm, das ein Programmcode-Mittel umfasst, welches so ausgelegt ist, dass es jeden der Verfahrenschritte nach einem der Ansprüche 1 bis 11 durchführt, wenn das Programm auf einem Rechner ausgeführt wird.