Einführung

Technisch gesehen geht es bei der DFN-AAI um eine bestimmte Spielart des webbasierten Single Sign-On (Web-SSO). Dieses Verfahren erlaubt es Anwendern, sich mit den Benutzer-Credentials, mit denen sie bei ihrer Heimateinrichtung registriert sind (i.d.R. Nutzername und Passwort), bei internen und externen Diensten anzumelden (Authentifizierung) und – entsprechende Berechtigungen vorausgesetzt (Autorisierung) – diese zu nutzen. Die hierfür erforderliche Infrastruktur, AAI (= Authentication and Authorization Infrastructure), wird traditionell im Rahmen nationaler Föderationen realisiert und in der Regel von den jeweiligen Forschungsnetzen betrieben. Im Fall der Bundesrepublik Deutschland ist dies der DFN-Verein.

Die technische Grundlage für solche Infrastrukturen bildet der Austausch von Metadaten, in denen die Identity Provider (IdP) der an der AAI teilnehmenden Heimatorganisationen (Bildungs- und Forschungseinrichtungen) und die Service Provider (SP) der teilnehmenden Dienstanbieter (Content-Provider, E-Learning-Plattformen, wissenschaftliche Dienste, etc.) registriert sind. Weiterhin existieren mit sogenannten Attribute Authorities externe Attributquellen, anhand derer ein SP zusätzliche, i.d.R. projektspezifische Nutzerdaten abrufen kann, die nicht von der Heimateinrichtung gepflegt werden. Bezeichnet werden solche Instanzen (IdP, SP, Attribute Authorities) auch als Entities. Bei den in den Metadaten hinterlegten Informationen handelt es sich sowohl um administrative (Organisation, Kontaktdaten) als auch um technische Daten (Service-Endpunkte, Zertifikate, etc.), die zur Kommunikation der Entities untereinander erforderlich sind. Als Standard hat sich hier flächendeckend SAML (Security Assertion Markup Language) durchgesetzt. Die Aufgabe der jeweiligen Föderation ist es, diese Datensätze zu pflegen, aktuell zu halten und sicherzustellen, dass innerhalb der Föderation ein sicherer und vertrauenswürdiger Austausch von Informationen stattfindet. Das technische Rückgrat einer solchen Föderation bilden somit die vom Föderationsbetreiber signierten Metadaten.

Weiterführende und vertiefende Informationen finden sich auf der Seite Weitere Informationsquellen und in diesem Foliensatz.

Eine Föderation agiert als Trusted Third Party, die die Einhaltung der technischen und rechtlichen Rahmenbedingungen sicherstellt und auf diese Weise ein Vertrauensverhältnis etabliert. In dieser Rolle übernimmt der Föderationsbetreiber (DFN) verschiedene Aufgaben:

• Verträge mit allen teilnehmenden Einrichtungen und Dienstanbietern, siehe unter Anmeldung
• Erstellen von Richtlinien (Policies) und Überwachung von deren Einhaltung
• Betrieb zentraler Lokalisierungsdienste: Discovery-Services, auch „WAYF“ genannt (Where Are You From), siehe unter Produktivbetrieb
• Verwaltung der Metadaten
• Support bei technischen Problemen und Fragen mit AAI-Bezug, siehe unter Kontakt
• Schulungen für teilnehmende Einrichtungen und Dienstanbieter (Schulungsanfragen richten Sie bitte an hotline@aai.dfn.de)

Siehe hierzu auch die Darstellung des Dienstportfolios der DFN-AAI.

Innerhalb einer Föderation wird vorausgesetzt, dass alle teilnehmenden Einrichtungen und Dienstanbieter gemeinsame Sicherheitsstandards zumindest in den folgenden Bereichen einhalten:

• Authentifizierung und Autorisierung von Nutzern,
• Zugriffskontrolle auf Ressourcen,
• Organisatorische und technische Prozesse, die durchlaufen werden, wenn eine Person in die Einrichtung aufgenommen wird, innerhalb der Einrichtung die Rolle ändert oder die Einrichtung verlässt.

Anbieter von Ressourcen wie z.B. einer kommerziellen Datenbank werden im AAI-Kontext als Service Provider bezeichnet. Service Provider vertrauen darauf, dass die verabredete Lizenzvereinbarung eingehalten wird. Steht eine bestimmte Datenbank z.B. nur Studierenden zur Verfügung, ist es wichtig, dass eine Person nach der Exmatrikulation nicht mehr auf diese Datenbank zugreifen darf. Besagt die Lizenzvereinbarung, dass nur Studierende einer bestimmten Fachrichtung auf die Ressource zugreifen dürfen, sind auch diese Attribute (hier: Studienfach) aktuell zu halten und bei Fächerwechsel zeitnah zu ändern.

Einrichtungen, deren Angehörige im Rahmen der AAI verfügbare Ressourcen/Dienste nutzen wollen, agieren als Identity Provider und sind für Authentifizierung und Attributierung zuständig. Für Identity Provider wird der Betrieb eines Identity Management Systems, mindestens aber einer vertrauenswürdigen Benutzerverwaltung mit konsistentem und aktuellem Datenbestand vorausgesetzt. Ein Identity Management System muss nicht als kommerzielles Produkt vorliegen, Systeme mit automatisierten Prozessen, die z.B. in OpenSource Software implementiert sind, werden als gleichwertig angesehen. Zum Austausch der Attribute muss es gemeinsame Datenschemata geben. Die obligatorisch und optional zu verwendenden Attribute sind hier dokumentiert.

Eine gute Einführung in das Thema Identity Management und AAI bietet die Präsentation von Thorsten Michels (Uni Kaiserslautern).

Vorausgesetzt wird der Betrieb eines Identity Management Systems oder mindestens einer vertrauenswürdigen Benutzerverwaltung, in denen Identitäten nach folgenden Prinzipien verwaltet werden:

• Personen, die in einer Einrichtung aufgenommen werden, erhalten eine digitale Identität.
• Identitäten erhalten Attribute, die der aktuellen Rolle der jeweiligen Person entsprechen.
• Werden Rolle oder Berechtigungen einer Person geändert, werden die Identitätsinformationen zeitnah angepasst.
• Für Personen, die die Einrichtung verlassen, wird die Identität mit allen Rechten und Rollen zeitnah gelöscht bzw. geändert (z.B. Studierende → Alumni).
• Die gängigen Attributschemata der DFN-AAI müssen unterstützt werden.
• Der Ressourcenanbieter (Service Provider) kann sich darauf verlassen, dass alle Änderungen zeitnah ausgeführt werden.
• Die Prozesse müssen soweit schriftlich dokumentiert werden, dass das Sicherheitsniveau aus der Dokumentation ableitbar ist.

Siehe hierzu auch unter Identity Assurance.

Die Motivation, eine AAI für die deutsche Hochschul- und Forschungscommunity zu schaffen, geht auf das vom BMBF geförderte AAR-Projekt (Authentifizierung, Autorisierung und Rechteverwaltung) zu­rück, das 2005 startete. Das wichtigste Ziel des Projekts war es, den Web-SSO-Zugriff auf lizenzierte elektronische Inhalte (Journals, Datenbanken, Bücher, etc.) zu ermöglichen, der gegenüber den herkömmlichen Methoden des Zugriffschutzes (IP-Kontrolle, VPN, Proxies) deutliche Vorteile bietet. Im Herbst 2007 wurde die DFN-AAI in den Regelbetrieb überführt und steht der DFN-Nutzerschaft seitdem als sogenannter Mehrwertdienst zur Verfügung. Nachdem anfangs die Hochschulbibliotheken die treibende Kraft in der DFN-AAI waren, kamen schnell weitere Anwendungsgebiete hinzu: Verteilung lizenzierter Software, hochschulinterne Dienste (lokale SP) sowie verschiedene E-Learning Plattformen. Spätestens mit dem Aufkommen föderierter (also AAI-fähiger) HPC-, Speicher-, Kommunikations- (Webconferencing) und Campus-Dienste, entwickelten auch die Hochschulrechenzentren ein Interesse an dem Betrieb AAI-relevanter Komponenten und lokaler Dienste.

In den letzten Jahren etablierten sich als weitere Akteure verschiedene Landesprojekte und -initiativen wie bwIDM, die Virtuelle Hochschule Bayern (VHB), Nds-AAI, SaxID, Kultusministerien und andere mehr, die ihre Dienste jeweils auf Landesebene verfügbar machen. Mit internationalen Forschungsverbünden und –infrastrukturen, die ihre Dienste föderationsübergreifend (eduGAIN) anbieten und nutzen wollen, ist der DFN-AAI seit einigen Jahren eine weitere wichtige Zielgruppe erwachsen, die mit ihren Bedürfnissen die traditionelle AAI vor neue Herausforderungen stellt. Als Beispiele seien hier CLARIN (Sprachressourcen), DARIAH (Geisteswissenschaften), ELIXIR (Life Science) und LIGO (Gravitationswellen-Forschung) genannt.