Die existierenden AAI-Konzepte lassen sich hinsichtlich der als Grundlage f¨ur den Dienst verwendeten Datenstrukturen kategorisieren. Diese Unterscheidung ist insbesondere
sinn-voll im Hinblick auf das Zusammenspiel einer AAI mit einem verteilten P2P-Verzeichnis f¨ur die Datenverwaltung. Wie im folgenden Abschnitt 3.3 analysiert, eignen sich unter-schiedliche Paradigmen (Client-Server bzw. Peer-to-Peer) als Grundlage f¨ur die Daten-verwaltung der verschiedenen AAI-Kategorien.
Die Beispielsysteme f¨ur die Kategorien werden nur knapp skizziert, da keine Festlegung auf ein bestimmtes System erfolgen soll. Stattdessen ist flexible Einsetzbarkeit des P2P-Verzeichnisses f¨ur m¨oglichst viele verschiedene AAI-Systeme angestrebt.
3.2.1 Online-AAI mit nicht zertifikatbasierter Datenhaltung
In einer Online-AAI werden die f¨ur die Dienste notwendigen Daten stets auf Anfrage eines Pr¨ufers spontan von einem Sicherheitsserver bereitgestellt. Dieser verf¨ugt daf¨ur ¨uber eine Datenbank, in welcher die entsprechenden Informationen - z.B. Passw¨orter und Zugriffs-listen - verwaltet werden. Bei einer Anfrage pr¨uft nun der Server seine Datenbankeintr¨age und generiert eine Antwort, z.B. in Form einer Authentizit¨atsbest¨atigung f¨ur die betref-fende Entit¨at1. Die Authentifizierung und Autorisierung kann also nur dann erfolgreich durchgef¨uhrt werden, wenn zum Zeitpunkt des A&A-Verfahrens eine direkte Verbindung zwischen dem Server und dem Pr¨ufer besteht.
Die dem Dienst zugrunde liegenden Daten sind dementsprechend Online-Informationen, d.h. sie m¨ussen bei jedem Authentifizierungs- und Autorisierungsvorgang f¨ur dieselbe Entit¨at neu angefragt werden.
Beispiele
Die Microsoft-Technologie.NET Passport[PASSP] [LOP03] erleichtert die Authentifi-zierung von Benutzern in Web-Umgebungen mittels Kombinationen von Benutzername und Passwort (im Folgenden kurzUnP : Username + Password). Die UnP-Kombinationen werden zentral auf einem Microsoft-Server gespeichert. Will sich ein Benutzer auf einer Partnerseite von .NET Passport einloggen, wird seine Anfrage an den .NET Passport Server weitergeleitet und ¨ubermittelt an diesen seine UnP-Kombination. Als Antwort erh¨alt er Cookies mit Authentizit¨atsinformationen f¨ur die Partnerseite, an welche die aktuelle Sitzung nun wieder umgeleitet wird. Vorteil dieser L¨osung ist die Single-Sign-On-Funktionalit¨at (SSO): es ist nicht notwendig, f¨ur jede der Partnerseiten eine eigene UnP-Kombination zu besitzen, sondern es gen¨ugt eine einzige f¨ur alle. Die Autorisierung von Benutzern findet dann wieder dezentral bei den einzelnen Partnerseiten statt, die ihre eigenen Autorisierungsschemata verwalten.
Liberty Alliance [LIBER] [LOP03] ist eine Allianz von ¨uber 160 Organisationen, z.B.
Verisign, AOL, Nokia, Visa, Sony und Sun Microsystems, mit dem Ziel der Generierung eines Standards f¨ur dezentralisierte SSO-Authentifizierung und offene Autorisierung im Web. Das Liberty-Alliance-System verwendet keine globale Kennung f¨ur einen Benutzer, sondern f¨ordert die Verbundbildung und den Datenaustausch zwischen den Teilnehmer-seiten, bei denen ein Benutzer verschiedene Kennungen besitzen kann.
Die Dienstanbieter interagieren mit sogenanntenIdentity Providers, welche die Authenti-fizierung der Benutzer durchf¨uhren und dann R¨uckmeldung an den Dienstanbieter geben.
1Diese kann auch ein kurzlebiger digital signierter Datensatz (Zertifikat) sein. Die Kategorisierung der AAI ergibt sich aufgrund derlangfristigenSpeicherform und damit der Art des Dienstangebots.
Ebenso liefernAttribute Providers Informationen ¨uber Eigenschaften von Benutzern, so dass der Dienstanbieter auf dieser Basis eine Entscheidung treffen kann, ob ein Benutzer uber die entsprechenden Berechtigungen verf¨ugt.¨
Entgegen dem Microsoft-Ansatz arbeitet Liberty auf Basis offener Standards wie SOAP [BaN04] und SAML [CKP05] und stellt den Partnern die Umsetzung des Standards in verschiedene Implementierungen frei2. Die zu verwendenden Authentifizierungsmethoden sind prinzipiell nicht festgelegt; es herrscht aber auch hier UnP-Authentifizierung auf Ba-sis von Datenbanken vor.
Shibboleth [SHIBB] ist eine im Rahmen des Internet2-Projektes [INTER] entwickelte und inzwischen insbesondere im akademischen Umfeld verbreitete AAI f¨ur browserbasier-te Diensbrowserbasier-te. Wie Liberty setzt Shibboleth auf offene Standards. Authentifizierung wird bei einer sogenannten Home Organization auf Basis ihrer Datenbanken durchgef¨uhrt. Sie lie-fert dann an den Ressourcenanbieter die Attribute des authentifizierenden Benutzers, anhand derer ihm der Anbieter Zugriff auf bestimmte Ressourcen erlaubt oder verwei-gert.
3.2.2 Offline-AAI mit zertifikatbasierter Datenhaltung
In einer zertifikatbasierten AAI bilden digital signierte Datens¨atze (Zertifikate) die Grund-lage f¨ur die Realisierung der Authentifizierung und Autorisierung.
Definition 3.4 Zertifikat
Ein Zertifikat ist ein elektronisches Dokument, in dem einer Entit¨at eine bestimmte Ei-genschaft, ein ¨offentlicher Schl¨ussel, ein Attribut oder eine Berechtigung zugeordnet und beglaubigt wird. Ein Zertifikat ist stets von einer Zertifizierungsstelle (Aussteller) unter Verwendung seines geheimen Signaturschl¨ussels digital signiert3.
Die Signatur kann von einem Pr¨ufer mit Hilfe des zum Signaturschl¨ussel geh¨orenden
¨offentlichen Testschl¨ussels des Ausstellers verifiziert werden.
Auf Basis der in den Zertifikaten enthaltenen Informationen werden Authentifizierung und Autorisierung zwischen einer Entit¨at und einem Anbieter dieser Dienste (Pr¨ufer) durchgef¨uhrt.
Ein Aussteller generiert ein Zertifikat und publiziert es dann in einem ¨offentlichen Ver-zeichnis, wo es von Pr¨ufern angefordert werden kann. Weiterhin werden R¨uckrufe oder G¨ultigkeitsbest¨atigungen (zusammenfassend als Statusnachrichten bezeichnet) in digital signierter oder aber in gehashter Form publiziert. Sie erlauben es einem Pr¨ufer zu er-mitteln, ob ein gegebenes Zertifikat, welches noch nicht sein regul¨ares G¨ultigkeitsende erreicht hat, vorzeitig vom Aussteller f¨ur ung¨ultig erkl¨art wurde oder nicht. Es ist also keine direkte synchrone Verbindung zwischen der Zertifizierungsstelle und dem Pr¨ufer zum Zeitpunkt des konkreten Authentifizierungs- und Autorisierungsverfahrens notwen-dig. Daher wird diese AAI als Offline-AAI bezeichnet.
Die Zertifikate und Statusnachrichten selbst geh¨oren zur Klasse der Offline-Informationen.
Sie k¨onnen nach einmaliger Anfrage aus dem Verzeichnis bei einem Pr¨ufer lokal gespei-chert und verwendet werden.
2z.B. existiert Liberty-Software in Java und C
3siehe Abschnitt 3.4.1
(a) Schl¨usselzertifikat (b) Attributzertifikat
Abbildung 3.1: Schematische Darstellung von Zertifikaten Beispiele
Im ITU-T-Standard X.509[HPF02] [Cha02] existieren neben den klassischen Schl¨ussel-zertifikaten f¨ur die Authentifizierung von Entit¨aten Attributzertifikate, welche beglau-bigte Informationen ¨uber Eigenschaften und Berechtigungen des Inhabers repr¨asentie-ren. Diese Zertifikate k¨onnen, m¨ussen aber nicht, nach Typ getrennt in unterschiedlichen Systemen gespeichert und verwaltet werden [DLM02], z.B. um in Firmen das Outsour-cing von Authentifizierungsdiensten zu erlauben, w¨ahrend die m¨oglicherweise vertrauli-chen Attribute im Rahmen einer Privilege-Management-Infrastruktur (PMI) intern vor-gehalten werden. Ein Beispiel f¨ur eine X.509-Implementierung ist der Dienst VOMS (Virtual Organization Membership Service) [ACC03], welcher f¨ur die Zugriffskontrolle auf Ressourcen in Grid-Umgebungen konzipiert ist. Auch AKENTIund PERMISals PMI-L¨osungen implementieren den X.509-Standard.
In SDSI/SPKI[ACM02] werden Zertifikate f¨ur die Zuordnung von ¨offentlichen Schl¨us-seln (f¨ur Authentifizierung) und Berechtigungen (f¨ur Autorisierung) zu Entit¨aten ver-wendet. Im Gegensatz zu X.509 existieren hier verschiedene Namensr¨aume, so dass die Bezeichnungen der Entit¨aten nicht global eindeutig sein m¨ussen. Ein weiterer Unter-schied zu X.509 ist der Aufbau der Attributzertifikate: anstatt eine Bindung zwischen einem Entit¨atsbezeichner und einem Attribut oder einer Berechtigung zu zertifizieren, wird in einem SDSI/SPKI-Attributzertifikat eine Zuordnung zwischen einem ¨offentlichen Schl¨ussel und einer Berechtigung beglaubigt. Nur in den Schl¨usselzertifikaten wird der Bezeichner der Entit¨at mit ihrem ¨offentlichen Schl¨ussel verkn¨upft. Die Entwickler des Systems empfehlen die dezentrale Speicherung der Zertifikate bei ihren Inhabern.