DE60214632T2

DE60214632T2 - Multidomäne Berechtigung und Authentifizierung

Info

Publication number: DE60214632T2
Application number: DE60214632T
Authority: DE
Inventors: Nigel John Westbury-on-Trym Edwards; Jason Ft. Collins Rouault
Original assignee: Hewlett Packard Development Co LP
Current assignee: Hewlett Packard Development Co LP
Priority date: 2001-07-27
Filing date: 2002-07-26
Publication date: 2007-04-26
Anticipated expiration: 2022-07-27
Also published as: GB0118439D0; EP1280317A1; EP1280317B1; GB2378010A; US20030023880A1; US7444666B2; DE60214632D1

Description

Die vorliegende Erfindung bezieht sich auf ein System zum Durchführen einer Multi-Domänen-Autorisierung und -Authentifizierung in einem Computernetzwerk.
Auf dem Gebiet von Computernetzwerken wird der Begriff „Domäne" bzw. „Bereich" (engl.: domain) gemeinhin dazu verwendet, auf einen Teil eines oder ein gesamtes Computernetzwerk Bezug zu nehmen, für den bzw. für das eine Gruppe von Benutzern einen Zugriff (möglicherweise unterschiedliche Zugriffsebenen) hat. In einer einzigen Organisation kann ein Computernetzwerk eine Anzahl unterschiedlicher Domänen aufweisen, die beispielsweise einer Forschungsabteilungsdomäne, einer Marketingabteilungsdomäne und einer Buchhaltungsabteilungsdomäne entsprechen. In einem viel größeren Maßstab kann ein Computernetzwerk multinational sein und kann eine Domäne umfassen, die sich auf eine Online-Website von E-Geschäftsbereichen bezieht, als eine Domäne, sowie eine Domäne für einen Internet-Dienstanbieter, der unabhängig von der Website des E-Unternehmens ist, bezieht.
Damit autorisierte Benutzer einer Domäne auf Informationen zugreifen können, die in anderen Domänen unterhalten werden, oder damit sie mit Benutzern in anderen Domänen kommunizieren können, ist eine Multi-Domänen-Autorisierung und -Authentifizierung erforderlich. Jede Domäne kann eine Privilegsverwaltungsinfrastruktur (PMI – Privilege Management Infrastructure) aufweisen, mit der verwaltet wird, welche Benutzer in der Lage sind, auf bestimmte Informationen zuzugreifen. Eine PMI kann als Einsteckmodul in einen Web-Server implementiert sein, der in ein Datenbankverwaltungssystem integriert sein kann, um unterschiedlichen Benutzern und unterschiedlichen Benutzertypen unterschiedliche Autorisierungen zu verleihen.
Eine PMI kann in Form eines Strategieentscheidungspunktes (PDP – Policy Decision Point) verwendet werden, der dazu benutzt werden kann, Informationen zu speichern und/oder zu auf dieselben zuzugreifen und Entscheidungen über Benutzer einer bestimmten Domäne, die Rollen des Benutzers sowie Einträge darüber, auf welche Teile des Systems dieser Benutzer zugreifen kann, zu treffen. Ein PDP gibt, nachdem ihm ein bestimmter Satz von Kriterien für einen Benutzer geliefert wurde, eine Entscheidung darüber aus, ob der Benutzer dazu autorisiert ist, auf Informationen zuzugreifen, bezüglich derer er einen Zugriff angefragt bzw. angefordert hat. Die Entscheidung kann auf dynamisch bereitgestellten Informationen und auch auf manchen gespeicherten Informationen beruhen.
Eine Entscheidung von einem PDP wird an einen Strategiedurchsetzungspunkt (PEP – Policy Enforcement Point) geleitet, der in demselben Teil eines Computersystems befindlich sein könnte wie ein PDP und dazu verwendet wird, die Entscheidung des PDP auszuführen. Ein PEP befindet sich in der Komponente, wo die Entscheidung durchgesetzt werden muss, und somit wäre der PEP bei einer standardmäßigen externen Website in einem Computersystem außerhalb einer Firewall-Sicherheitsabschirmung angeordnet, wohingegen ein PDP in einem Computer innerhalb dieser Firewall angeordnet wäre.
Ein vorhandenes Verfahren eines Zugriffs über Domänengrenzen hinweg, das eine über Domänengrenzen hinweg erfolgende Anmeldungs- und -Sitzungssynchronisation verwendet, beruht auf einer Verwendung von Attributzertifikaten. Ein vereinbarter Standard ist der Internet-X.509-Standard [X.509-1988]CCITT Recommendation X.509: The Directory – Authentication Framework. 1988; [X.509-1997]ITU-T Recommendation X.509: The Directory – Authentication Framework. 1997; und [X.509-2000]ITU-T Recommendation X.509: The Directory – Public-Key and Attribute Certificate Frameworks. 2000. Das Format von X.509-Zertifikatanfragenachrichten ist bei The Internet Engineering Task Force (IETF) Request for Comments (RFC) Nummer 2511 vom März 1999 (siehe www.ietf.org/rfc/rfc2511.txt) offenbart. In jenem Dokument ist ein Zertifikatanfragenachrichtformat (CRMF – Certificate Request Message Format) beschrieben, das eine Syntax ist, die dazu verwendet wird, eine Anfrage bzw. Anforderung bezüglich eines Zertifikats von einer Zertifizierungsautorität (CA – Certification Authority) zum Zweck einer Erstellung eines X.509-Zertifikats zu übermitteln. Eine derartige Anfrage umfasst üblicherweise einen öffentlichen Schlüssel und zugeordnete Registrierungsinformationen (wie nachstehend erörtert wird).
Bei vorhandenen Multi-Domänen-Autorisierungs- und -Authentifizierungssystemen werden häufig Zertifikate benutzt, die die Verwendung einer Öffentlicher-Schlüssel-Kryptographie erfordern, was einen öffentlichen Schlüssel und einen privaten Schlüssel zur Verschlüsselung umfasst. Ein öffentlicher Schlüssel ist, wie sein Name sagt, öffentlich verfügbar und ist in einem Zertifikat enthalten. Der öffentliche Schlüssel wird dazu verwendet, eine durch einen Anfragenden ausgegebene Anfrage zu entschlüsseln und dadurch zu gewährleisten, dass die Anfrage durch einen Inhaber eines privaten Schlüssels, der dem öffentlichen Schlüssel zugeordnet ist, erstellt wurde. Umgekehrt kann eine mit dem öffentlichen Schlüssel verschlüsselte Meldung bzw. Nachricht lediglich durch den Inhaber des privaten Schlüssels entschlüsselt werden. Ein privater Schlüssel wird üblicherweise von dem Eigentümer des privaten Schlüssels an einem sicheren Ort aufbewahrt, möglicherweise auf einer Floppy-Disk, noch üblicher jedoch in einem bestimmten Teil des Computers eines Benutzers.
Gewöhnliche X.509-Zertifikate können für eine einzige Anmeldung verwendet werden. PMIs können Zertifikate an ihre Kunden bzw. Clients ausstellen, die noch kein Zertifikat haben.
Unter dem SAML-Standard (security assertion markup language – Sicherheitsaktivierung-Markup-Sprache) der OASIS (Organization for Advancement of Structural Information Standards – Organisation zur Förderung von strukturellen Informationsstandards) (ein XML-Format – siehe www.oasisopen.org/committees/security/index.shtml) würde alternativ dazu, wenn ein Benutzer eine Sitzung an einer Site beginnt, ein kurzlebiges Attributzertifikat (das Angaben bezüglich der Identität und bestimmter Informationen des Benutzers wie z. B. finanzielle Informationen oder Bankangaben, bei dem Beispiel einer Online-Einkaufs-Website, umfassen kann) ausgestellt, das Sitzungsinformationen erfasst, die während der Sitzung eingegeben werden, und sie anderen Sites zur Verfügung stellt.
Der OASIS-SAML-Standard verwendet das Konzept einer ausstellenden Behörde, die signierte Erklärungen (die auch als Attributzertifikate bezeichnet werden könnten) ausstellt, wobei diese Erklärungen durch einen PDP empfangen werden. Bei dem OASIS-Format ist ein PDP lediglich dafür verantwortlich, Entscheidungen zu treffen, nicht dafür, Erklärungen zu erzeugen. Bei der vorliegenden Erfindung ist die ausgebende Behörde mit dem PDP zusammengelegt. Jedoch könnte das beschriebene System gleichermaßen im Rahmen des OASIS SAML implementiert werden. Die nachfolgend beschriebene Implementierung verwendet X.509- und CRMF-Protokolle. OASIS verwenden XML-Codierung, für ein erfolgreiches Implementieren der Erfindung können jedoch beide verwendet werden.
Es wird anerkannt, dass ein attraktives Verfahren, bei dem ein Benutzer in der Lage wäre, auf mehrere Domänen in einem Computernetzwerk zuzugreifen, darin bestünde, dass ein Benutzer für mehrere Domänen eine einzige Anmeldung aufweist. Der Zweck einer einzigen Multi-Domänen-Anmeldung besteht darin, zu vermeiden, dass ein Benutzer aufwendige Handlungen vornehmen muss, um sich erneut zu authentifizieren, wenn sich der Benutzer von einer Site zu einer anderen Site in beispielsweise einem anderen Unternehmen bewegt. Stattdessen gewährleisten der Clientcomputerserver des Benutzers und die angeforderten Server, dass die für die neue Site benötigte Authentifizierung automatisch erfolgt. Dadurch wird das häufig auftretende Problem vermieden, dass man sich unterschiedliche Passwörter für unterschiedliche Sites merken muss. Dadurch wird das Benutzererlebnis deutlich verbessert. Eine Sitzungssynchronisation verbessert eine einzige Anmeldung dahin gehend, eine Unterstützung bezüglich eines Austauschs von Informationen zu umfassen, die der jüngsten Aktivität des Benutzers auf einer gegebenen Site zugeordnet sind.
Der Zweck einer Multi-Domänen-Autorisierung besteht darin, Domänen in die Lage zu versetzen, auf sichere Weise Informationen auszutauschen, die zur Autorisierung verwendet werden können. Ein PDP in einer Domäne muss vielleicht ein bestimmtes Attribut des Kunden bzw. Client wissen, das lediglich von einer anderen Domäne geliefert werden kann, beispielsweise den finanziellen Status des Kunden. Cookies wurden bereits vorgeschlagen und als Möglichkeit eines Transferierens von Authentifizierungs- und Sitzungsinformationen zwischen Sites verwendet. Dieser Lösungsansatz weist eine Reihe von Problemen auf. Cookies funktionieren nicht gut über Domänengrenzen hinweg, da ein Erzeugen eines Cookies in einer Site, das an eine andere Site gesendet werden soll, in Browsern nicht sehr unterstützt wird, da es ein Sicherheitsrisiko bedeutet. Außerdem können Cookies durch einen Angreifer im Transit (wenn sie nicht über eine sichere Serververknüpfung gesendet werden) und von der Platte des Computers eines Benutzers erfasst werden, um abgespielt zu werden. Der Angreifer sieht dann wie der legitime Kunde mit dem Cookie aus (dies wird als Täuschungsangriff bezeichnet).
Ein weiterer Lösungsansatz, der zum Transferieren von Authentifizierungs- und Sitzungsinformationen von einer Site zu einer anderen vorgeschlagen wird, ist das URL- Codieren (URL = Universal Resource Locator – Einheitsressourcenlokator). In diesem Fall erzeugt dann, wenn ein Benutzer einem Link von einer Site zu einer anderen Site folgt, die erste Site auf dynamische Weise den URL, der auf die zweite Site zeigt. Die zweite Site erkennt den dynamisch erzeugten URL von der ersten Site und ist in der Lage, aus demselben Sitzungs- und Authentifizierungsinformationen zu extrahieren. Dies erlegt dem Computer zusätzliche Leistungsanforderungen auf (um die URLs dynamisch zu erzeugen) und ist schwierig zu implementieren, wenn die Site viele statische HTML-Seiten (HTML = Hypertext Mark-up Language) aufweist, da die statischen Seiten durch den Server bearbeitet werden müssen, damit die Links dynamisch ersetzt werden.
Als Möglichkeit zum Implementieren von Multi-Domänen-Authentifizierung und -Autorisierungen wurden auch bereits Proxies vorgeschlagen. Proxies weisen zweifelhafte Skalierungseigenschaften auf, da alle Anfragen über den Proxy gesendet werden, der zu einer Engstelle werden könnte. Außerdem sind Unternehmen bezüglich ihrer Sicherheit nicht gerne von einem Proxy eines anderen Unternehmens abhängig. Es gibt schwierige Vertrauens- und Verwaltungsbelange. Außerdem ist der Proxy auch ein besonders wertvolles Ziel für einen potentiellen Angreifer.
Um eine einzige Multi-Domänen-Anmeldung ohne die Verwendung von Cookies, Proxies oder einer URL-Umschreibung zu erzielen, wird die Verwendung von X.509-Zertifikaten empfohlen. Dies erfordert, dass alle Benutzer ein X.509-Zertifikat aufweisen, das durch eine teilnehmende PMI ausgestellt und signiert sowie mit einer Zertifizierungsautorität (CA) verkettet ist. Alternativ dazu können die öffentlichen Schlüssel von Zertifikatausstellern als Teil der Unternehmenslogik des Systems in die PMIs konfiguriert sein. Der PEP jeder PMI könnte dann wählen, das Clientzertifikat des Endbenutzers zum Identifizieren des Benutzers zu verwenden, oder, auf der Basis der Unternehmenspolitik, verlangen, dass sich der Benutzer unter Verwendung eines alternativen Mechanismus (beispielsweise eines Tokens oder biometrischer Informationen) authentifiziert. Letzteres, was als Form von sekundärer oder/bzw. Erweiterungsauthentifizierung fungiert, wird nachstehend erörtert.
Für den Fall, dass ein Benutzer noch kein Clientzertifikat besitzt, sollte jede PMI die Möglichkeit liefern, auf eine Selbstregistrierung eines Benutzers hin ein X.509-Zertifikat auszustellen und zu signieren. Diese durch die PMI ausgestellten Zertifikate werden mit einer üblicherweise CA (oder einem Satz von CAs) in einer Kette von Zertifikaten verkettet, wobei jedes durch eine höhere CA bis zu einer Wurzel-CA authentifiziert wird.
In vielen Fällen kann eine Einzelanmeldung je nach der angefragten Ressource verschiedene Authentifizierungsarten erfordern. Beispielsweise kann der Benutzer, der auf Steuereinbehaltungsinformationen zugreift, eine Authentifizierung auf Zertifikatbasis benötigen, wohingegen derselbe Benutzer, der auf seine Gesundheitsunterlageninformationen zugreift, eine von biometrischer Authentifizierung benötigen mag. Unter vielen Umständen besteht die Art und Weise, wie eine PMI ein derartiges Szenario vielleicht handhabt, darin, dass, wenn der Benutzer zunächst auf die Steuereinbehaltungsinformationen zugreift, das Zertifikat des Benutzers dazu verwendet wird, die Person zu identifizieren. Wenn der Benutzer während der Sitzung einen Zugriff auf seine Gesundheitsunterlagen anfordert, wird er durch die PMI aufgefordert, sich unter Verwendung einer Biometrik erneut zu authentifizieren. Dies wird oft als „Erweiterungsauthentifizierung" („step-up authentication") bezeichnet.
Wenn PMIs eine Erweiterungsauthentifizierung in einer Multi-Domänen-Umgebung implementieren, wird es wichtig, über die Domänen hinweg mitzuteilen, wie sich der Benutzer authentifiziert hat, so dass die PMI den Benutzer nicht jedes Mal, wenn eine Authentifizierungsebene benötigt wird, die höher ist als ein bestimmtes Zertifikat erlaubt, den Benutzer erneut auffordert, einen Berechtigungsnachweis zu liefern. Dies bedeutet, dass irgendeine Form von Sitzungsinformationen, im Minimalfall des Authentifizierungstyps, über Domänen hinweg gemeinsam genutzt werden muss.
Ein Lösungsansatz bezüglich eines gemeinsamen Nutzens derartiger Sitzungsinformationen kann unter Verwendung einer PDP-zu-PDP-Kommunikation erzielt werden, die später erörtert wird. Der öffentliche Schlüssel in dem Zertifikat des Benutzers kann dazu verwendet werden, den Benutzer eindeutig zu identifizieren. Um die Sitzung des Benutzers eindeutig zu identifizieren (wenn man annimmt, dass die Entität mehrere Sitzungen unterstützt), ist eine eindeutige Sitzungs-ID nötig. Nachdem ein Benutzer unter Verwendung seines Zertifikats authentifiziert wurde, befähigt dies einen PDP in z. B. einer Domäne 1, einen PDP in z. B. einer Domäne 2 nach Sitzungsinformationen über diesen bestimmten Benutzer zu befragen. Der PDP der Domäne 1 kann den PDP der Domäne 2 fragen, wie sich der Benutzer authentifiziert hat. Der PDP der Domäne 1 kann dem PDP der Domäne 2 genügend Vertrauen entgegenbringen, um den Benutzer nicht zu bitten, erneut eine biometrische Authentifizierung vorzulegen, falls die Domäne 2 sagt, dass der Benutzer dies bereits getan hat. Somit fordert PDP1 das Zertifikat (das Sitzungsinformationen umfasst) von PDP2 an.
Man geht davon aus, dass jede PMI-Implementierung minimale Zustandsinformationen unterhält.
Ein Problem bei dem oben erörterten Lösungsansatz besteht darin, wie der PDP einer bestimmten Domäne bestimmt, mit welchen anderen Domänen (und deren PDPs) er in Bezug auf Sitzungsinformationen kommunizieren sollte. Eine mögliche Lösung dieses Problems besteht darin, Informationen über die Sitzung des Benutzers in dem X.509-Zertifikat (Attributzertifikat) des Benutzers zu speichern. Dem Benutzer würde dann nach jeder erfolgreichen Authentifizierung gegenüber einer PMI ein neues X.509-Attributzertifikat ausgestellt. Dieses Attributzertifikat würde derartige Dinge enthalten wie z. B. wie, wann und wo sich der Benutzer authentifiziert hat. Um jedoch ein derartiges Szenario zu unterstützen, würde dies erfordern, dass der Browser des Benutzers in der Lage ist, Attributzertifikate entsprechend zu verwalten. Beispielsweise würde das Erstellen eines neuen Attributzertifikats durch die PMI auf eine erfolgreiche Authentifizierung hin die Aktualisierung oder Überschreibung jeglicher zuvor ausgestellter Attributzertifikate erfordern.
Aktuelle handelsübliche Browser weisen begrenzte Zertifikatverwaltungsfähigkeiten auf. Browser wie z. B. Microsoft Internet Explorer und Netscape Navigator wären nicht in der Lage, eine derartige Verwaltung von X.509-Attributzertifikaten, wie sie oben umrissen wurde, zu unterstützen. Die einzige Möglichkeit, die Unzulänglichkeiten dieser Browser zu umgehen, wäre die Verwendung von clientseitigen Komponenten (d. h. eines Browser-Einsteckmoduls). Die Verwendung derartiger clientseitiger Komponenten ist nicht immer beliebt, da die meisten Endbenutzer nicht bereit sind, Software auf ihren Geräten zu installieren. Jedoch ist das Problem des Installierens einer derartigen Software in den Fällen, bei denen derartige clientseitigen Komponenten in der gesamten Branche verwendet und durch die gesamte Branche unterstützt werden, auf ein Minimum reduziert. Beispielsweise läuft der Adobe Acrobat Reader als Browser-Einsteckmodul, und die meisten Benutzer haben kein Problem damit, ihn zu installieren, da sie wissen, dass PDF-Dokumente in der Branche Standard sind und dass das Acrobat Reader-Einsteckmodul zum Einsehen dieser Dokumente erforderlich ist. Wenn zur Unterstützung einer Authentifizierung und Autorisierung über Domänengrenzen hinweg ein Browser-Einsteckmodul erforderlich wäre, wäre es nur dann akzeptabel, wenn es in der gesamten Branche angenommen würde.
Eine Einzelanmeldung auf der Basis einer Öffentlicher-Schlüssel-Verschlüsselung für Web-Browser ist für solche Benutzer problematisch, die nicht immer dasselbe physische Gerät verwenden, oder für Benutzer, die einen Zugriff auf ein physisches Gerät mit anderen gemeinsam nutzen. Es wird eine Möglichkeit benötigt, Schlüsselmaterial und Sicherheitsberechtigungsnachweise auf dynamische Weise herunterzuladen.
Das zuvor erwähnte Browser-Einsteckmodul wäre herunterladbar und wäre somit für mobile Benutzer problemlos von jeglichem physischem Gerät aus zu verwenden.
1 zeigt schematisch, wie ein sicherer, über Domänengrenzen hinweg arbeitender Web-Server funktionieren kann.
Die Bezugszeichen in 1 beziehen sich auf die folgenden Ereignisse.

1. Ein Benutzer 10 fordert eine geschützte Ressource in einer Domäne 1 an und wird aufgefordert, sich zu authentifizieren.
2. Die PMI 11 in der Domäne 1 authentifiziert den Benutzer 10 und stellt dem Benutzer ein X.509-Attributzertifikat aus, das Sitzungsinformationen in Bezug darauf enthält, wie, wann und wo sich dieser Benutzer 10 authentifiziert hat.
3. Der Browser des Benutzers 10 akzeptiert das neue Zertifikat, wobei er jegliches bereits vorhandene über Domänengrenzen hinweg vorliegende Authentifizierungs-/-Autorisierungszertifikat aktualisiert oder überschreibt.
4. Der Benutzer 10 fordert eine geschützte Ressource in der Domäne 2 an, wobei er das neu erzeugte Attributzertifikat von der Domäne 1 weiterleitet.
5. Die PMI 13 in der Domäne 2 bestimmt auf der Basis der in dem Attributzertifikat des Benutzers gespeicherten Sitzungsinformationen, ob für die angeforderte Ressource eine erneute Authentifizierung oder Erweiterungsauthentifizierung erforderlich ist.
6. Wenn der Benutzer 10 in der Domäne 2 erneut authentifiziert wird, so wird ein neues Attributzertifikat erzeugt und dem Benutzer ausgestellt, andernfalls wird dem Benutzer vertraut, und es wird ihm ohne weitere erneute Authentifizierung Zugriff gewährt.

Der obige Lösungsansatz erlegt Browsern und Clients die folgenden Anforderungen auf. Das System muss in der Lage sein, Attributzertifikate zu unterstützen. Ferner muss das System in der Lage sein, ein vorhandenes Zertifikat zu ersetzen oder zu aktualisieren. Ferner ist es möglich, einen Browser oder Client von dem Web-Server zu treiben, um ihn dazu zu bringen, Schlüsselpaare zu erzeugen. Ferner können Clients und Server mehrere Zertifikate austauschen, wenn sie eine SSL-Protokollsitzung (SSL = Secure Socket Layer – Sicherheitssockelschicht) einrichten. Dies wurde in dem ursprünglichen SSL-Entwurf, der 1995 veröffentlicht wurde und der sich lediglich mit serverseitigen Zertifikaten beschäftigte, festgelegt. Er ist in TLS (Transport Level Security – Sicherheit auf der Transportebene), dem IETF-Standardspurprotokoll, das SSL ersetzen sollte, enthalten, siehe Request for Comments (RFC) (Anfrage nach Kommentaren) 2246 (z. B. bei www.ietf.org/rfc/rfc2246.txt) sowohl bezüglich Clients als auch Servern. Es ist nicht klar, wie verbreitet die Unterstützung dieses Merkmals tatsächlich ist. Insbesondere wissen wir einfach nicht, was geschieht, wenn Attributzertifikate in der Abfolge von präsentierten Zertifikaten enthalten sind. Zusätzlich zu dem oben Gesagten werden Servern und PMIs Anforderungen bezüglich dessen auferlegt, Zertifikate auszustellen und minimale Sitzungszustandsinformationen zu unterhalten.
Ein Lösungsansatz für den Austausch von Autorisierungsinformationen zwischen Domänen besteht darin, HTTP (hypertext transfer protocol – Hypertextübertragungsprotokoll) als Transport zu verwenden. Dies hat den Vorteil, dass die Protokollinfrastruktur bereits installiert ist, nachdem sie im Gebrauchm für das Internet in großem Umfang implementiert wurde. 2 zeigt ein einfaches Szenario, bei dem der PDP 11 in der Domäne 1 Strategieinformationen von dem PDP 13 in der Domäne 2 einholen muss. Die Art von Informationen, die benötigt werden könnte, könnte in dem Beispiel folgende sein: „Ist Joe für 100 $ gut"? bzw. Kann Joe 100 $ zahlen?" oder „Ist Joe ein Goldcard-Kunde?".
Die Bezugszeichen in 2 beziehen sich auf die folgenden Schritte:

1. Anforderung von Joe durch den PDP 11 der Domäne 1 empfangen, der PDP 11 der Domäne 1 benötigt Strategieinformationen von der Domäne 2.
2. Der PEP 15 der Domäne 1 fordert eine Autorisierung von dem PDP 11 der Domäne 1 an.
3. Der PDP 11 der Domäne 1 fordert eine Autorisierung von der Domäne 2 an.
4. Der PEP 17 der Domäne 2 erkennt die Autorisierungsanfrage (an) und leitet sie an den PDP 11 der Domäne 2 weiter.

Bei diesem Szenario liefert Joe 10, wenn er sich bei der Domäne 1 registriert, die URLs des Dritten (oder der Dritten), der relevante Informationen über ihn, z. B. seine Kreditwürdigkeit, liefern kann. Alternativ kann der URL in die Geschäftslogik der Domäne 1 eincodiert werden.
Dann beginnt Joe 10, die Site in der Domäne 1 zu nutzen, und er kommt an einen Punkt, wo der PDP 11 in der Domäne 1 wissen muss, ob Joe 10 in der Domäne 2 ein „Goldcard"-Kunde ist. Der PDP 11 der Domäne 1 erstellt ein unsigniertes Attributzertifikat, das das „Goldcard"-Attribut enthält, und sendet es unter Verwendung von HTTP an den URL für die Domäne 2. Dies könnte unter Verwendung des HTTP-Postverfahrens, das in der IETF RFC 1945 dokumentiert ist (siehe z. B. www.ietf.org/rfc/rfc1945.txt), implementiert werden, um Nachrichten vom Zertifikatanfragenachrichtformat (CRMF-Nachrichten) (gemäß der Offenbarung in der oben erwähnten RFC 2511) zu führen. Dies weist den Vorteil auf, dass die vorhandene HTTP-Autorisierungsinfrastruktur erneut verwendet werden kann, um zu steuern, wer Autorisierungsanfragen durchführen kann. Autorisierungsdaten können aufgrund von Datenschutzbelangen sensibel sein. Dies impliziert, dass die CRMF-Nachricht ebenfalls authentifiziert werden muss. Zusätzlich muss die CRMF-Nachricht verschlüsselt werden. Dies könnte unter Verwendung von HTTP/SSL (Hypertext Transfer Protocol/SSL) implementiert werden. Jedoch weist dieser Lösungsansatz einige Schwächen auf, wie nachfolgend erörtert wird.
Angenommen, Joe weist einen „Goldcard"-Status auf, und der PDP 11 der Domäne 1 ist autorisiert, eine derartige Anfrage in der Domäne 2 durchzuführen, so signiert ansprechend auf die Anfrage der PDP 13 der Domäne 2 das Zertifikat mit einem entsprechenden Gültigkeitszeitraum und sendet es zurück. Der PDP 11 in der Domäne 1 hat nun alle Informationen, die er benötigt, um Joe zu autorisieren, und er kann das Zertifikat auch zum Zweck einer späteren Nutzung speichern (bis es nicht mehr gültig ist). Der PDP 11 muss nun die Gültigkeit von durch Dritte ausgestellten Zertifikaten verwalten. Hierfür könnte OCSP (online certificate status protocol – Online-Zertifikatstatusprotokoll), wie es bei IETF RFC 2560 offenbart ist, verwendet werden (siehe z. B. www.ietf.org/rfc/rfc2560.txt). Alternativ dazu könnten die PDPs 11, 13 CRLs austauschen oder einfach warten, bis ein Zertifikat im Begriff ist, abzulaufen, und ein neues Zertifikat anfordern.
Wenn Joe in der Domäne 2 keinen „Goldcard"-Status aufweist, muss der PDP 13 der Domäne 2 eine Fehlermeldung zurücksenden. Wir können nicht von einer direkten SSL-Verbindung zwischen den PDPs 11, 13 ausgehen, und somit ist ein Zurücksenden einer einfachen Fehlermeldung (z. B. verwehrt) ohne Kontext nicht ausreichend. Ein Angreifer könnte eine zuvor aufgeschnappte Verwehrt-Nachricht abspielen, bevor der PDP 13 der Domäne 2 mit einem Zertifikat antwortet, das vielleicht einen Zugriff erlaubt. Auf diese Weise könnte der Angreifer einen Zugriff verwehren. Es gibt mehrere Optionen, eine Fehlermeldung zurückzusenden, einschließlich der folgenden:

– ein Zertifikat wird mit dem negierten Attribut, z. B. „Goldcard verwehrt", zurückgesendet. Der Gültigkeitszeitraum dieses Zertifikats könnte verwendet werden, um zu prüfen, dass es sich um eine aktuelle Information handelt;
– ein Zertifikat, das ein spezielles „Verwehrt"-Attribut enthält, wird zurückgesendet. Hierbei ist darauf zu achten, dass dies zu dem angeforderten Attribut passt – dies würde durch Verwendung des Hash-Werts der Anfrage als Identifizierer erfolgen.

Eine kryptographische Hash-Funktion ist ein Mechanismus eines Erzeugens eines eindeutigen Identifizierers (üblicherweise als Hash-Wert bezeichnet) aus einem Dokument (üblicherweise 128 Bits oder länger). Sie weisen die Eigenschaft auf, dass es extrem unwahrscheinlich ist, dass zwei Dokumente denselben Hash-Wert erzeugen. Außerdem ist es extrem schwierig, das Dokument ausgehend von dem Hash-Wert zu erzeugen. Dies bedeutet, dass es schwierig ist, ein anderes Dokument zu erzeugen, das denselben Hash-Wert aufweist wie ein gegebenes Dokument. Eine oft verwendete Analogie lautet, dass er der Fingerabdruck der Daten ist. In der Literatur sind mehrere hinreichend bekannte Hash-Algorithmen dokumentiert, die jedem Fachmann bekannt sind. Diese umfassen SHA-1 und MD5.
Nun sei angenommen, dass der PDP 11 der Domäne 1 ein dynamisches Attribut von Joe 10 bestätigen muss, beispielsweise kann er 100 $ zahlen? Man kann sich an genau dieselben Verfahrensweisen halten, wie sie oben beschrieben wurden. Der Unterschied besteht darin, dass das in dem Zertifikat enthaltene Attribut in diesem Fall „Kauf über 100 $" ist und dass das durch den PDP 13 der Domäne 2 zurückgesendete Zertifikat einen Null aufweisenden oder sehr kurzen Gültigkeitszeitraum aufweist. Man beachte, dass der PDP 13 der Domäne 2, obwohl er vielleicht nicht beabsichtigt, dass dieses Zertifikat wieder verwendet wird, nicht verhindern kann, dass es wieder verwendet wird. Wahrscheinlich ist beim Umgang hiermit besser, sich auf eine Anwendungslogik und soziale oder legale Protokolle zu stützen: Im Fall einer Streitigkeit bekommt die Domäne 1 vielleicht lediglich maximal 100 $ für jedes Zertifikat, das sie produzieren kann, bezahlt.
Man beachte, dass eine Konsequenz des Obigen darin besteht, dass der Kommunikationsfluss in Wirklichkeit folgendermaßen verläuft: von dem PDP 11 der Domäne 1 → Web-Server 19 der Domäne 2 → PEP 17 der Domäne 2 → PDP 13 der Domäne 2. Bei dieser Art von Fluss müsste der PEP 15, 17 wissen, wie auf eine Autorisierungsanfrage hin zu agieren ist, die von einem PDP 11, 13 in einer anderen Domäne kommt.
Autorisierungsinformationen können als vertraulich erachtet werden. In diesem Fall wäre es nicht wünschenswert, derartige Informationen unverschlüsselt auszutauschen. Das Einfachste wäre, eine HTTP/SSL-Verbindung von dem PDP 11 der Domäne 1 zu dem Web-Server 19 der Domäne 2 herzustellen.
Dies würde uns ermöglichen, die vorhandene Autorisierungsinfrastruktur zu nutzen, um zu gewährleisten, dass der PDP 11 der Domäne 1 autorisiert ist, diese Informationen zurückzugewinnen. Beispielsweise möchte ein Kreditkartenunternehmen vielleicht nicht jedem x-Beliebigen erlauben, abzufragen, ob einer seiner Karteninhaber für den Kauf von Waren im Wert von 100 $ gut ist oder eine Goldcard besitzt. Vielmehr möchte das Unternehmen diese Informationen vielleicht lediglich „anerkannten" Verkäufern gegenüber enthüllen.
Ferner ist zu beachten, dass Autorisierungsinformationen eventuell vor einer Wiedergabe geschützt werden müssen. Wenn wir es beispielsweise mit dynamischen Sitzungsinformationen zu tun haben, so könnten Angreifer, wenn sie die Autorisierung wiedergeben könnten, in der Lage sein, die Gültigkeit der Sitzung aufrechtzuerhalten, nachdem der Benutzer sie geschlossen hatte.
Wir gingen bisher davon aus, dass es nicht möglich oder wünschenswert ist, zwischen PDPs 11, 13 eine direkte TCP-Verbindung zu haben. Kunden möchten den PDP 11, 13 vielleicht nicht einer direkten Verbindung vom Internet aussetzen (noch sich mit der Öffnung zusätzlicher Tore in der Firewall beschäftigen). Deshalb wird eine Kommunikation zwischen PDPs 11, 13 durch Web-Server 19, 21 weitergeleitet. Ungünstigerweise ist dies aufgrund der Beschränkungen von HTTP/SSL keine Ende-zu-Ende-Lösung (PDP zu PDP). Stattdessen vertrauen wird dazwischenliegenden Web-Servern und PEPs 15, 17, dass sie die CRMF-Nachrichten oder -Antworten nicht enthüllen oder manipulieren.
Eine Ende-zu-Ende-Lösung erfordert ein Protokoll, das gegenüber SSL ähnliche Garantien liefert, jedoch in einer Mehrsprungumgebung arbeiten können. Hewlett-Packard hat ein derartiges Protokoll-„Sitzungsschichtsicherheit"-Protokoll (SLS-Protokoll – SLS = „session layer security", Sitzungsschichtsicherheit) als Bestandteil seiner e-Sprechen- Plattform entwickelt. Dieses Protokoll ist ein Offene-Quelle-Protokoll. Dieses Protokoll ermöglicht einen sicheren Austausch von Nachrichten zwischen den PDPs 11, 13, die durch dazwischenliegende Web-Server über HTTP weitergeleitet werden.
Die Verwendung von CRMF, um Autorisierungsanfragen zu senden, ermöglicht es uns, Autorisierungsanfragen zu bündeln (mehrere Zertifizierungsanfragen können in einer einzigen Nachricht vorgenommen werden). Eine einzige CRMF-Nachricht könnte durch mehrere PDPs 11, 13 geleitet werden, wobei jeder PDP 11, 13 eines oder mehrere der Zertifikate ausstellt. Ein derartiges Szenario ist bei IETF RFC 2905 (siehe z. B. www.ietf.org/rfc/rfc2905.txt) der Internet Society beschrieben. Mehrsprungszenarios wie dieses verwandeln PDPs 11, 13 in Weiterleitungsmaschinen für Autorisierungsanfragen. Dadurch entsteht eine Anfälligkeit für manche der Fallen des Weiterleitens gleichartiger Nachrichtenschleifen. Eine Sprungzählung könnte darin nützlich sein, diese zu vermeiden.
Außerdem könnte sich die Sicherheit bei einem Mehrsprungszenario als Herausforderung erweisen. Während die CRMF-Anfrage von dem PDP 11, 13 weitergeleitet wird, müssen einige der folgenden Belange betrachtet werden.

– sollten alle PDPs 11, 13 in der Lage sein, alle Elemente der CRMF-Anfrage zu sehen? Vielleicht sollten manche Elemente so verschlüsselt werden, dass lediglich bestimmte PDPs sie sehen können;
– wenn Zertifikate zu der Nachricht hinzugefügt werden, wie werden diese vor einer nicht-autorisierten Enthüllung oder vor einer nicht-autorisierten Beseitigung aus der Nachricht geschützt?;
– wie werden Routings- bzw. Weiterleitungsinformationen codiert?

Wenn zwei Sites eine große Menge an Autorisierungsinformationen austauschen, so stellen sie vielleicht fest, dass das Signieren jedes Zertifikats einen beträchtlichen Leistungszusatzaufwand bedeutet. Sie können wählen, eine sichere Sitzung (unter Verwendung eines entsprechenden Protokolls) einzurichten und unsignierte Zertifikate auszutauschen, wobei sie davon ausgehen, dass diese sicher sind, und sie so behandeln, als ob der andere Beteiligte sie signiert hat. Jedoch liefert dies keinen Schutz vor einer Nicht-Zurückweisung. Ein Beteiligter könnte unsignierte Autorisierungsinformationen senden und später das Senden derselben leugnen. Ein Kompromiss könnte darin bestehen, den Hash-Wert einer Abfolge von unsignierten Zertifikaten zu signieren.
Eines der Probleme bei dem oben erläuterten Lösungsansatz bezüglich einer Multi-Domänen-Autorisierung besteht darin, dass Joe nicht vergessen darf, die von ihm bereitgestellten Registrierungsinformationen jedes Mal dann, wenn sie sich ändern, beispielsweise wenn er die Bank wechselt, zu aktualisieren. Dies ist wahrscheinlich nicht allzu beschwerlich, wenn er bei einer einzigen Site registriert ist. Wenn er jedoch bei mehreren Sites registriert ist, vergisst er vielleicht, sie alle rechtzeitig zu aktualisieren.
Somit beschreibt das von OASIS online veröffentlichte Dokument HALLAM BAKER P: „Security Assertions Markup Language. Core assertion Architecture – Examples and Explanations" ein Computernetzwerksystem, das in jeder einer Mehrzahl von Domänen eine Privilegsverwaltungsinfrastruktur aufweist, die folgende Merkmale umfasst:
zumindest einen Strategiedurchsetzungspunkt, an den ein Benutzer eine Anfrage bezüglich eines Zugriffs auf Informationen oder einen Dienst in dem Netzwerk richten kann, wobei diese Informationen oder dieser Dienst eine Autorisierung für einen Zugriff erfordern beziehungsweise erfordert, wobei dem Benutzer durch den Strategiedurchsetzungspunkt Zugriff auf die angefragten Informationen oder den angefragten Dienst gewährt wird, wenn die Anfrage akzeptiert wird; und
zumindest einen Strategieentscheidungspunkt in dem Computernetzwerk, von dem ein Strategiedurchsetzungspunkt eine Autorisierung anfragen kann, damit der Benutzer auf die Informationen oder den Dienst zugreifen kann, wobei der Strategieentscheidungspunkt dazu angepasst ist, ein oder mehr Attributzertifikate, die dem Benutzer zugeordnet sind, zu verifizieren.
Diese Erfindung liefert ein System des oben beschriebenen Typs, gekennzeichnet durch
zumindest einen Meta-Strategieentscheidungspunkt zum Zweck einer Multi-Domänen-Autorisierung und/oder -Authentifizierung, wobei sich der Meta-Strategieentscheidungspunkt bei einem von dem Benutzer unabhängigen Beteiligten befindet, in dem ein oder mehr Attributzertifikate des Benutzers und/oder Positionsadressen, von denen derartige Attributzertifikate angefragt werden können, vorab gespeichert und an einer dem Benutzer bereitgestellten Positionsadresse zugänglich sind, und mittels dessen die Strategieentscheidungspunkte dahingehend angeordnet sind, aus der Positionsadresse Attributzertifikate herauszusuchen, die benötigt werden, um eine Benutzeranfrage zu bearbeiten.
Das System kann eine Mehrzahl von Meta-Strategieentscheidungspunkten umfassen.
Das System kann einen dem Strategiedurchsetzungspunkt zugeordneten World-Wide-Web-Server umfassen, wobei die Anfrage des Benutzers an den World-Wide-Web-Server erfolgt.
Die Positionsadresse für die Autorisierungs-Authentifizierungsinformationen und/oder weitere Informationen des Benutzers ist vorzugsweise die Adresse des MPDP, am stärksten bevorzugt eine Unteradresse des MPDP, die einzig an den Benutzer vergeben ist.
Der MPDP kann ein oder mehrere digitale Zertifikate des Benutzers halten. Der MPDP kann ein oder mehrere Passwörter und/oder Benutzernamen des Benutzers zum Zweck eines Zugriffs auf Informationen oder Dienste halten. Der MPDP kann Schlüsselpaare für digitale Zertifikate halten.
Der MPDP kann persönliche Bankangaben und/oder Kreditkarten-/Chargecard-Angaben des Benutzers halten oder kann Adressangaben für einen Computer einer Bank eines Benutzers oder medizinische Informationen/andere persönliche Informationen des Benutzers halten.
Die in dem MPDP gehaltenen Informationen können durch den Benutzer verändert werden, beispielsweise um die Informationen zu aktualisieren.
Der MPDP kann Informationen in Bezug auf die Position eines anderen Computers, vorzugsweise eines PDP eines Computers, halten, der Autorisierungs-/Authentifizierungsinformationen oder eine Bestätigung von Autorisierungs-/Authentifizierungsinformationen liefern kann.
Der MPDP liefert vorteilhafterweise eine einzige Position für Autorisierungs-/Authentifizierungsinformationen eines Benutzers zur Lieferung an andere Computer in einem Computernetzwerk, zusammen mit einer einzigen Position für Online-Berechtigungsnachweise eines Benutzers, z. B. Bankangaben.
Der MPDP kann Informationen in Bezug darauf halten, welchen Beteiligten ein Benutzer Autorisierungs- /Authentifizierungsinformationen zu liefern bereit ist, wobei der MPDP durch den Benutzer dahin gehend programmierbar ist, die Beteiligten festzulegen.
Der MPDP kann Informationen darüber speichern, welche Dritten auf Informationen, die den Benutzer betreffen, von dem MPDP zugegriffen haben.
Der MPDP kann eine Zertifizierungsautorität (CA) sein, die Servern, die Dienst-/Informationsanbieter sein können, digitale Zertifikate ausstellen kann, um diesen Servern eine Zugehörigkeit zu einem Handelsplatz zu verleihen.
Der MPDP kann einen Berechtigungsentzug und eine erneute Validierung eines Benutzers erteilen. Der MPDP kann Informationen bezüglich eines Berechtigungsentzugs von einem Dienstanbieter empfangen und kann diese Informationen dazu verwenden, Autorisierungs-/Authentifizierungsinformationen eines Benutzers über den MPDP zu modifizieren.
Der oder jeder MPDP oder PDP kann sich hinter einer Firewall befinden.
Die Erfindung erstreckt sich auf einen Computer, der dahin gehend programmiert ist, die Funktion des oben beschriebenen MPDP zu erfüllen.
Die Erfindung erstreckt sich auf ein aufzeichnungsfähiges Medium, das ein Computerprogramm aufweist, das dahin gehend wirksam ist, die Funktionen des MPDP zu erfüllen.
Alle obigen Aspekte können in jeglicher Kombination mit jeglichen der hierin offenbarten Merkmale kombiniert werden.
Ein spezifisches Ausführungsbeispiel der vorliegenden Erfindung wird nun beispielhaft und unter Bezugnahme auf die beiliegenden Zeichnungen beschrieben, bei denen:
1 eine schematische Darstellung einer Kommunikation zwischen einem Benutzer ist, der Informationen von zwei getrennten Domänen benötigt;
2 eine schematische Darstellung eines Beispiels einer durch einen Benutzer vorgenommenen Anfrage ist, wobei die Anfrage an eine erste Domäne erfolgt und diese Anfrage Informationen von einer zweiten Domäne benötigt; und
3 ein schematisches Diagramm ist, das eine Implementierung eines Meta-Strategieentscheidungspunktes (MPDP – Meta Policy Decision Point) zeigt, die die Interaktion zeigt, die verwendet wird, wenn ein Benutzer Informationen von einer ersten Domäne anfragt, wobei die Domäne Informationen von weiteren Domänen erfordert, durch eine Verwendung eines MPDP; und
4 ein schematisches Diagramm eines Strategieauswerters, dem Vertrauen entgegengebracht wird, zur Fernauswertung von Zugriffssteuerungsstrategien ist.
Um dem Problem zu begegnen, dass sich ein Benutzer 10 mehrere Passwörter merken muss und daran denken muss, mehrere Seiten von Registrierungsinformationen zu aktualisieren, wird ein System zur Verwaltung der Online-Persona einer Person verwendet. Das System wird als Meta-Strategieentscheidungspunkt (MPDP) 12 bezeichnet (siehe 3).
Kurz gesagt, wenn sich ein Benutzer 10 bei der Domäne 1 registriert, liefert er den URL seines MPDP 12, statt die URLs (Einheitsressourcenlokatoren) für den Strategieentscheidungspunkt (PDP) seiner Bank zu liefern. Der Benutzer hat den URL seiner Bank bereits bei dem MPDP registriert.
Wenn eine erste Domäne, PDP 16 der Domäne 1, Autorisierungsinformationen von einem Dritten benötigt, sendet er/sie eine Zertifikatanfragenachrichtformat-Anfrage (CRMF-Anfrage, CRMF = certificate request message format), die die Attribute, die zu autorisieren sind, enthält, an den MPDP 12, den der Benutzer 10 angab, als er sich bei der Domäne 1 registrierte. Der MPDP 12 des Benutzers kann die Attribute entweder direkt zurücksenden oder kann die Anfrage an den entsprechenden PDP 18, 20 umleiten. Dies ist in 3 gezeigt. Es ist möglich, dass eine Umleitung eventuell keine Option ist, falls die CRMF-Nachricht mehrere Zertifizierungsanfragen enthält.
In 3 beziehen sich die Bezugszeichen auf die folgenden Anfragen und den folgenden Vorgang:

1. Anfrage von Joe, der Strategieinformationen von der Domäne 2 benötigt.
2. Der Strategiedurchsetzungspunkt (PEP) 24 der Domäne 1 fragt eine Autorisierung von dem PDP 16 der Domäne 1 an.
3. Der PDP 16 der Domäne 1 fragt eine Autorisierung von dem MPDP 12 an.
4. Der MPDP 12 fragt Autorisierungsinformationen von den Domänen 2 und 3 an.
5. PEPs 26, 28 erkannten eine Anfrage bezüglich Autorisierungsinformationen und leiten sie an ihre jeweiligen PDPs 18, 20 weiter.

Das Protokoll zwischen dem PDP 16, 18, 20 und dem MPDP 12 sollte Integrität, Geheimhaltung gewährleisten und eine Authentifizierung beider Beteiligten ermöglichen. Dieses Protokoll sollte dasselbe sein wie das oben beschriebene PDP-zu-PDP-Protokoll – somit erfordert der MPDP 12 keine weitere Standardisierungsaktivität. Es ist wahrscheinlich, dass eine Autorisierung benötigt wird, bevor der MPDP 12 die CRMF-Anfrage akzeptiert. Ein Modell besteht darin, dass der MPDP lediglich Anfragen von PDPs akzeptiert, die der Benutzer ausdrücklich autorisiert hat – siehe unten.
Das Hauptkonzept hinter dem MPDP 12 besteht darin, dass er einen Ort liefert, an dem ein Benutzer 10 seine Online-Persona verwaltet. Wenn sich der Benutzer anfänglich bei dem MPDP 12 registriert, stellt er ihm ein Attributzertifikat aus, das seinen persönlichen URL enthält. Anschließend kann er das Zertifikat präsentieren, wenn er seine Identität verwalten möchte. Beispiele dieser Art von Informationen, die der Benutzer eventuell verwaltet, lauten:

– wer kann auf welche (Autorisierungs-) Informationen über ihn zugreifen;
– wer hat auf welche Autorisierungsinformationen über ihn zugegriffen;
– Ändern der URLs für PDPs, die Autorisierungsinformationen über ihn erzeugen.

Der MPDP 12 liefert auch einige zusätzliche nützliche Funktionen. Er könnte als Marktregulierungsbehörde agieren, die Zertifikate an Dienstanbieter ausstellt und ihnen dabei eine Zugehörigkeit zum Handelsplatz verleiht. Dienstanbieter könnten diese Zertifikate dazu verwenden, den Austausch von Sitzungsinformationen zu autorisieren, oder sie könnten sie zur Wiedergewinnung von Autorisierungsinformationen nutzen.
Eine natürliche Erweiterung besteht darin, dass der MPDP 12 eine sichere Speicherung für Zertifikate und Schlüsselpaare eines Benutzers liefert, so dass sie in jegliche beliebige Vorrichtung, die der Benutzer gerade zufällig benützt, heruntergeladen werden könnten. Innerhalb des IETF arbeitet eine neue Arbeitsgruppe (Securely Available Credentials (SACRED) – siehe z. B. www.ietf.org/html.charters/sacredcharter.html) daran, ein Protokoll zum Unterstützen des Obigen zu standardisieren. Dadurch wird eines der Hauptprobleme gelöst, das mit einer Verwendung von Zertifikaten für eine einzige Anmeldung verbunden ist, das nämlich darin besteht, dass gewisse Probleme entstehen können, wenn der Benutzer nicht immer dieselbe Vorrichtung verwendet oder eine gemeinsam genutzte Vorrichtung verwendet. Die vorliegende Erfindung löst diese Probleme.
Der Zusammenschluss der MPDPs 12 erfordert keine weitere Technologie. Die MPDPs 12 enthalten URLs, die auf PDPs oder andere MPDPs zeigen. Das Protokoll, anhand dessen mit PDPs 16, 18, 20 und MPDPs 12 gesprochen wird, ist dasselbe. Das System kann durch Verwendung der Sprache JAVA und XML implementiert werden. Alternativ dazu könnten das Obige und das nachstehend Beschriebene unter Verwendung des SAML-Rahmens implementiert werden, der von der Oasis-Organisation (oben erwähnt) vorgeschlagen wird – siehe z. B. www.oasis-open.org/index.shtml.
MPDPs 12 sind ferner in der Lage, auf sinnvolle Weise an einem Berechtigungsentzug und einer erneuten Validierung teilzunehmen. Ein MPDP 12 kann nicht nur Benutzern 10 ermöglichen, zu steuern, wer Zertifikate, die Informationen über sie enthalten, wiedergewinnen kann, der MPDP 12 kann außerdem Angehörige des Marktes davon benachrichtigen, wenn die Berechtigungsnachweise eines Benutzers 10 ungültig werden. Er kann dies beispielsweise tun, wenn Joe seinen „Goldcard"-Status verliert. Dies könnte durch die Verwendung einer Zertifikatentzugsliste (CRL – certificate revocation list) implementiert werden, wie sie in Bezug auf digitale Zertifikate bereits häufig eingesetzt wird.
Der MPDP 12 liefert als Dienst auch eine Berechtigungsnachweissammlung, indem er alle Zertifikate für einen einzigen Benutzer bündelt und sie validiert und eine einzige sig nierte Struktur ausstellt. Andere PDPs 16, 18, 20 können sich entscheiden, dem MPDP 12 dahin gehend zu vertrauen, dass er diese Art von Validierung für sie vornimmt. Einer der Vorteile hieraus besteht darin, dass die Verwaltung für die PDPs 16, 18, 20 dadurch leichter wird, da sie sich nicht darum kümmern müssen, Informationen über alle möglichen Ausstellungsbehörden auf dem neuesten Stand zu halten.
Der MPDP 12 kann statt lediglich einer Liste von Ressourcen, die für einen Benutzer zugänglich sind, allgemeine Attribute speichern. Die allgemeinen Attribute umfassen z. B. „Goldcard"-Status oder Angaben zur Kredithöchstgrenze usw.
Ob ein Beteiligter einem MPDP 12 bezüglich dieses letztgenannten Vorgangs vertraut oder nicht, ist eine Frage der Einschätzung. Es könnte Haftbarkeitsprobleme für den Betreiber des MPDP 12 in Bezug auf diesen Dienst geben. Ferner wäre es notwendig, zu fragen, wie vertrauenswürdig die Quellen der MPDP-Daten sind, es könnte eine Autorisierung von einer Vielzahl von Quellen ansammeln, von denen einige weniger vertrauenswürdig sind als andere. Beispielsweise könnte man sich vorstellen, dass der MPDP 12 in einer großen Organisation das Unternehmensverzeichnis als Informationsquelle verwendet.
Wenn sich ein Benutzer 10 bei einem Dienst eines MPDP 12 registriert, liefert er URLs von echten PDPs und möglicherweise andere Profilinformationen wie z. B. Bankkontonummern und dergleichen. Dabei gibt es Geheimhaltungsbelange. Der Benutzer 10 vertraut dem MPDP 12, dass er diese Informationen nicht missbraucht. Eine Lösung dieses Problems besteht darin, dass der Benutzer 10 die Informationen in dem MPDP 12 so verschlüsselt, dass der MPDP 12 sie nicht lesen kann. Als Bestandteil eines Registrierens bei einem Dienst oder Portal liefert der Benutzer 10 den oder die Schlüssel, die benötigt werden, um die Informationen zu entschlüsseln, die er in dem Eintrag des MPDP 12 des Benutzers sehen muss.
Eine Folge dieses Lösungsansatzes besteht darin, dass der MPDP 12 nicht mehr transparent wäre. Die PDPs 16, 18, 20 müssten ein anderes Protokoll zum Sprechen mit demselben verwenden.
Der vertrauenswürdige Strategieauswerter (TPE – Trusted Policy Evaluator) 30 ist eine vertrauenswürdige (Hardware-) Maschine zur Fernauswertung von Zugriffssteuerungsstrategien. Ein mögliches Szenario ist in 4 gezeigt.
Bei diesem Szenario lädt der Dienst S (bei Pfeil 1) seine Strategie für einen Zugriff auf den TPE 30, der sich in einer Domäne 32 eines Benutzers 10 befindet, hoch. Der TPE weist einen Zugriff auf die Berechtigungsnachweise des Benutzers sowie auf die Strategie für einen Zugriff auf S auf. Wenn die Berechtigungsnachweise des Benutzers mit der Strategie im Einklang stehen, stellt der TPE 30 dem Benutzer 10 ein Ticket (Zertifikat) für einen Zugriff auf S aus. S sieht niemals die Berechtigungsnachweise des Benutzers 10 direkt, und der Benutzer 10 sieht niemals die Strategie, die einen Zugriff auf S steuert (niemand in der Domäne des Benutzers sieht sie).
Der MPDP 12 könnte dies als Dienst Benutzern 10 und Dienstanbietern anbieten. Für diese Arbeit wäre eine gemeinsame Strategiesprache nötig sowie ein gemeinsames Format für Autorisierungsattribute. Dies bedeutet, dass der MPDP 12 (oder die MPDPs – wahrscheinlich sind es viele) sich darum kümmern müsste, alle Berechtigungsnachweise wiederzugewinnen und in Bezug auf Zugriffssteuerungsstrategien zu prüfen.
Ein alternatives Szenario besteht darin, zu argumentieren, dass es bei dem MPDP 12 im Grunde darum geht, wie Autorisierungsattribute zu finden und wiederzugewinnen sind. Bei dem TPE 30 geht es im Grunde darum, wie diese Attribute in Bezug auf Zugriffssteuerungsstrategien zu bewerten sind, während die Attribute und Strategien vertraulich behandelt werden. Der TPE 30 könnte den MPDP 12 dazu verwenden, Autorisierungsattribute wiederzugewinnen. Somit könnte der TPE 30 als separate Maschine neben dem MPDP 12 betrieben werden.
Es scheint, dass ein Betreiben eines TPE 30 in oder neben dem MPDP 12 ein natürlicher Entwicklungsschritt ist, nachdem die MPDPs 12 eingesetzt wurden.
Die Vorteile eines MPDP 12 für seine Benutzer 10 wären folgende:

– Bereitstellung eines Ortes, um Informationen wie z. B. Bankangaben, Informationen über das persönliche Profil usw. zu aktualisieren;
– ein Benutzer 10 kann steuern, wer auf Informationen über ihn von dem MPDP 12 zugreifen kann (einschließlich eines Entzugs dieses Privilegs);
– der Benutzer 10 kann sehen, wer auf welche Informationen über ihn zugreift;
– der Benutzer 10 kann seine digitale Persona (Schlüssel und Zertifikate) in jegliche Vorrichtung herunterladen, dies sorgt für Mobilität;
– der Benutzer 10 kann den MPDP 12 dazu verwenden, bestimmte Informationen für zielgerichtete Werbungszwecke (durch den MPDP 12) öffentlich verfügbar zu machen, beispielsweise kann er Informationen senden, die sein Interesse an bestimmten Produkten oder Diensten bekunden;
– der MPDP 12 kann sich schließlich zu einem persönlichen Portal entwickeln, das Email-Konten usw. liefert.

Es ist möglich, dass eine große Organisation, die vielleicht MPDPs 12 betreibt, um ihre interne PMI-Infrastruktur zu treiben, ihren Angestellten nicht erlaubt, über die gesamte oben erwähnte Steuerung zu verfügen.
Für den Betreiber des oben beschriebenen MPDP 12 bestehen die Vorteile darin, dass ein die Form eines Unternehmens aufweisender Betreiber eines MPDP 12 einen Ort zum Verwalten digitaler Identitäten hätte, um die PMIs in seinem Intranet zu treiben, und dass er ferner einen Platz zum Verwalten von Gültigkeits- und Entzugs- bzw. Widerrufsinformationen hätte.
Für einen Betreiber eines Internet-MPDP 12 würden die Vorteile darin bestehen, dass aus zielgerichteter Werbung Einkünfte hervorgehen; Gebühren könnten pro Autorisierung von Dienstanbietern verlangt werden, wenn sie den Dienst nutzen, um Autorisierungsinformationen einzuholen. Ferner könnte es Dienstanbietern bezüglich ausgestellter Zertifikate in Rechnung gestellt werden, dass sie Zugehörige des Handelsplatzes sind.
Die Vorteile für Dienstanbieter bestehen darin, dass ihren Benutzern eine angenehmere Erfahrung zuteil wird und dass eine bessere Regulierung des Handelsplatzes vorliegt, die durch einen Begriff einer Zugehörigkeit und den verwalteten Entzug und die verwaltete erneute Validierung von Multi-Domänen-Berechtigungsnachweisen geliefert wird.
Bei der Implementierung ist der MPDP 12 von gewöhnlichen PDPs 16, 18, 20 solange nicht zu unterscheiden, bis er beginnt, in einer Marktregulierungsrolle zu agieren, und/oder bis er beginnt, für Autorisierungsinformationen Gebühren zu verlangen. Bis zu diesem Zeitpunkt nehmen Dienstanbieter einen PDP wahr, an den sie CRMF-codierte Informationsanfragen senden.
Der oben beschriebene MPDP 12 soll als Sicherheits-E-Dienst verwendet werden. Der MPDP 12 erfordert keinen weiteren Standardisierungsaufwand. Er liefert einen einzigen Punkt zur Verwaltung von Gruppen von PMIs, indem er einen Weiterleitungsdienst für Autorisierungsanfragen bereitstellt; er weiß, wo die einem gegebenen Benutzer zugeordneten Autorisierungsinformationen zu bekommen sind. Er liefert einen einzigen Punkt zum Verwalten einer Online-Persona oder von Online-Berechtigungsnachweisen eines Benutzers. Er liefert Marktregulierungsdienste, wobei er Benutzern und Diensten bescheinigt, dass sie Zugehörige des Handelsplatzes sind, und indem er Informationen über den Entzug von Berechtigungen verteilt. Er könnte als Dienst im Intranet sowie im Internet eingesetzt werden. Die Funktion eines MPDP 12 könnte über die Sicherheit hinaus erweitert werden, beispielsweise könnten Benutzerprofilinformationen für zielgerichtete Werbung verkauft werden, vorbehaltlich der Einwilligung von Benutzern.
Man plant, dass es nicht einen einzigen MPDP geben wird, sondern dass viele Unternehmen MPDPs ohne zentrale Kontrolle bzw. Steuerung betreiben werden. Die MPDPs können gemäß der obigen Beschreibung zusammenarbeiten. Die Mehrzahl von getrennten MPDPs soll sich der sozialen, legalen und Vertrauenswürdigkeitsprobleme annehmen, die entstehen würden, wenn eine globale Autorität oder eine globale Unternehmung für die Verwaltung sensibler (Sicherheits-) Informationen verantwortlich wäre. Ferner wurde gezeigt, wie der MPDP eine der Barrieren bezüglich einer Verwendung einer Öffentlicher-Schlüssel-Verschlüsselung beseitigen könnte.
Im Obigen wurde ein Ziehen-Modell (engl.: pull model) für eine Autorisierung erörtert: ein PDP 16, 18, 20, der Autorisierungsinformationen von anderen PDPs 16, 18, 20 anfragt. Manchmal könnte ein Schieben-Modell (engl.: push model) Vorteile aufweisen, besonders bezüglich der Verwendung derselben Protokolle, um Sitzungsinformationen zu verteilen. Ein Schieben-Modell beinhaltet das Senden von Informa tionen an einen anderen PDP, ohne dass zuerst eine Anfrage von demselben empfangen wurde.

Claims

Ein Computernetzwerksystem, das in jeder einer Mehrzahl von Domänen eine Privilegsverwaltungsinfrastruktur aufweist, die folgende Merkmale umfasst: zumindest einen Strategiedurchsetzungspunkt (24, 26, 28), an den ein Benutzer (10) eine Anfrage bezüglich eines Zugriffs auf Informationen oder einen Dienst in dem Netzwerk richten kann, wobei diese Informationen oder dieser Dienst eine Autorisierung für einen Zugriff erfordern beziehungsweise erfordert, wobei dem Benutzer durch den Strategiedurchsetzungspunkt (24, 26, 28) Zugriff auf die angefragten Informationen oder den angefragten Dienst gewährt wird, wenn die Anfrage akzeptiert wird; und zumindest einen Strategieentscheidungspunkt (16, 18, 20) in dem Computernetzwerk, von dem ein Strategiedurchsetzungspunkt (24, 26, 28) eine Autorisierung anfragen kann, damit der Benutzer auf die Informationen oder den Dienst zugreifen kann, wobei der Strategieentscheidungspunkt (16, 18, 20) dazu angepasst ist, ein oder mehr Attributzertifikate, die dem Benutzer zugeordnet sind, zu verifizieren; wobei das System durch folgendes Merkmal gekennzeichnet ist: zumindest einen Meta-Strategieentscheidungspunkt (12) zum Zweck einer Multi-Domänen-Autorisierung und/oder -Authentifizierung, wobei sich der Meta-Strategieentscheidungspunkt bei einem von dem Benutzer (10) unabhängigen Beteiligten befindet, in dem ein oder mehr Attributzertifikate des Benutzers und/oder Positions adressen, von denen derartige Attributzertifikate angefragt werden können, vorab gespeichert und an einer dem Benutzer bereitgestellten Positionsadresse zugänglich sind, und mittels dessen die Strategieentscheidungspunkte (16, 18, 20) dahingehend angeordnet sind, aus der Positionsadresse Attributzertifikate herauszusuchen, die benötigt werden, um die Benutzeranfrage zu bearbeiten.
Ein System gemäß Anspruch 1, das eine Mehrzahl von Meta-Strategieentscheidungspunkten umfasst.
Ein System gemäß Anspruch 1 oder Anspruch 2, das einen dem Strategiedurchsetzungspunkt zugeordneten World-Wide-Web-Server umfasst, wobei die Anfrage des Benutzers an den World-Wide-Web-Server erfolgt.
Ein System gemäß einem der vorhergehenden Ansprüche, bei dem die dem Benutzer bereitgestellte Positionsadresse eine Unteradresse eines Meta-Strategieentscheidungspunktes ist, wobei die Unteradresse einzig an den Benutzer vergeben ist.
Ein System gemäß einem der vorhergehenden Ansprüche, bei dem der Meta-Strategieentscheidungspunkt persönliche Bankangaben und/oder Kreditkarten-/Chargecard-Angaben des Benutzers hält.
Ein System gemäß einem der vorhergehenden Ansprüche, bei dem der Meta-Strategieentscheidungspunkt Adressangaben für einen Computer einer Bank eines Benutzers oder medizinische Informationen/andere persönliche Informationen des Benutzers hält.
Ein System gemäß einem der vorhergehenden Ansprüche, bei dem die bei dem Meta-Strategieentscheidungspunkt gehaltenen Informationen durch den Benutzer veränderbar sind, um die Informationen zu aktualisieren.
Ein System gemäß einem der vorhergehenden Ansprüche, bei dem der Meta-Strategieentscheidungspunkt Informationen in Bezug darauf hält, welchen Beteiligten der Benutzer Autorisierungs-/Authentifizierungsinformationen zu liefern bereit ist.
Ein System gemäß Anspruch 8, bei dem der Meta-Strategieentscheidungspunkt durch den Benutzer dahingehend programmierbar ist, die Beteiligten festzulegen.
Ein System gemäß einem der vorhergehenden Ansprüche, bei dem der Meta-Strategieentscheidungspunkt Informationen darüber speichert, welche Dritten auf Informationen, die den Benutzer betreffen, von dem Meta-Strategieentscheidungspunkt zugegriffen haben.
Ein System gemäß einem der vorhergehenden Ansprüche, bei dem der Meta-Strategieentscheidungspunkt eine Zertifizierungsautorität (CA) ist, die Servern digitale Zertifikate ausstellt, um diesen Servern eine Zugehörigkeit zu einem Handelsplatz zu verleihen.
Ein System gemäß einem der vorhergehenden Ansprüche, bei dem der Meta-Strategieentscheidungspunkt dazu angeordnet ist, einen Berechtigungsentzug und eine erneute Validierung eines Benutzers zu erteilen.
Ein System gemäß einem der vorhergehenden Ansprüche, bei dem der Meta-Strategieentscheidungspunkt dazu angeordnet ist, Informationen für einen Berechtigungsentzug von einem Dienstanbieter zu empfangen, und diese Informationen dazu verwendet, Autorisierungs-/Authentifizierungsinformationen eines Benutzers an dem Meta-Strategieentscheidungspunkt zu modifizieren.
Ein Computer, der dazu programmiert ist, die Funktion des in einem der Ansprüche 1 bis 13 definierten Meta-Strategieentscheidungspunkt zu erfüllen.
Ein aufzeichnungsfähiges Medium, das ein Computerprogramm aufweist, das dahingehend wirksam ist, die Funktion des in einem der Ansprüche 1 bis 13 definierten Meta-Strategieentscheidungspunkt zu erfüllen.