AARC TREE erfolgreich abgeschlossen – Interoperabilität in der Forschung weitergedacht

Interview mit David Hübner, Solutions Engineer

David, wir wollen heute über die EU-Initiative AARC sprechen, genauer über das jüngste Folgeprojekt, nämlich AARC TREE. Bevor wir dazu kommen, kannst du uns zum Einstieg kurz erklären, wofür AARC eigentlich steht und welches Problem das Projekt ursprünglich lösen wollte?

Ja, sehr gerne. AARC steht für Authentication and Authorization in Research and Collaboration, und TREE steht für Technical Revision to Enhance Effectiveness. Es ist ein sehr schönes Akronym mit ganz vielen komplizierten Worten (lacht).
AARC – die beiden A’s sagen es ja – Authentifizierung und Autorisierung. Das heißt, es geht um den Aufbau von AAIs, also Infrastrukturen, mit denen Authentifizierung und Autorisierung gemacht wird. Research Collaboration, also RC, bezieht sich auf Forschungsinfrastrukturen im Allgemeinen. Das heißt, es geht letztendlich darum, wie man es schafft, in föderierten – also dezentralen – Systemen auf Ressourcen zuzugreifen, sich zu authentifizieren und zu beweisen, dass ich Zugriffsrechte auf bestimmte Ressourcen habe.
Was sich im Laufe der Jahre entwickelt hat, ist ein sehr chaotischer Zustand, weil jede Forschungsinfrastruktur ihre eigenen technischen Lösungen aufgebaut hat, was zu Inkompatibilitäten führt. Es gab unterschiedliche technische Niveaus und unterschiedliche Lösungen. AARC hat sich damals, als die erste Projektphase 2015 angefangen hat, zum Ziel gesetzt, diese ganzen unterschiedlichen Lösungen zusammenzubringen und zu vereinheitlichen, sodass Interoperabilität sichergestellt wird.
Der Begriff, der sich daraus entwickelt hat, ist auch die Lösung, die aus diesen AARC-Projekten am weitesten verbreitet ist, die BPA. BPA steht für Blueprint Architecture. Das ist eine Blaupause mit verschiedenen Bausteinen, wie man technisch eine interoperable AAI in Forschungsinfrastrukturen aufbaut.
AARC TREE ist jetzt die dritte Projektphase. Es gab also zwei Projektphasen davor, und wir [DAASI International] waren in allen drei Phasen beteiligt. In den ersten beiden Phasen wurden die Grundlagen gelegt – zum Beispiel wurden die Blueprint Architecture oder auch auf Policy-Ebene Beispiel-Dokumente und Richtlinien geschaffen, die die Basis bilden. In AARC TREE wurde nicht so viel komplett Neues geschaffen, sondern mehr auf dem Bestehenden aufgebaut, um es für die neuesten Entwicklungen fit zu machen.

Du warst von Anfang an dabei. Was genau ist denn deine Rolle im AARC-Projekt?

In den ersten beiden Projektphasen, also AARC 1 und 2 – AARC 1 war von 2015 bis 2017, AARC 2 dann von 2017 bis 2019 – waren wir in fast allen Arbeitspaketen aktiv. Wir waren im Architektur-Arbeitspaket, also in dem Paket, in dem die BPA entstanden ist und die ganzen technischen Dokumente – also welche Protokolle verwendet werden und wie technische Lösungen aussehen. Wir waren damals auch im Policy-Arbeitspaket drin, das heißt, wir haben an der Entstehung von Richtlinien und Policies wie z. B. SIRTFI zur Handhabung von Sicherheitsvorfällen in föderierten Systemen, mitgearbeitet. Außerdem waren wir in den ersten beiden AARC-Projekten auch im Arbeitspaket Pilots aktiv, wo wir die technischen und Policy-Lösungen in konkreten Pilotprojekten umgesetzt und erprobt haben. Als Vertreter von DARIAH, der Forschungsinfrastruktur für Geisteswissenschaften, haben wir damals die AARC-Ergebnisse in der DARIAH-AAI umgesetzt.
In AARC TREE waren wir nun etwas weniger involviert und haben uns stark auf die Architektur fokussiert. Wir waren in allen technischen Bereichen dabei und ich habe an der Entwicklung der neuen Version der Blueprint Architecture – also der BPA 2025 – und an den Spezifikationen und Dokumenten, die neben dieser BPA leben und einzelne Aspekte dieser Gesamtarchitektur im Detail beschreiben, mitgewirkt.

Ich habe kürzlich den Blogbeitrag zum offiziellen Abschluss der zweijährigen Projektphase von AARC TREE mit den Ergebnissen gelesen. Was würdest du persönlich als die wichtigsten Ergebnisse von AARC TREE hervorheben wollen?

Das ist immer eine schwierige Frage, weil natürlich alles irgendwie wichtig ist. Wenn man es übergreifend betrachtet, würde ich sagen, sind in AARC TREE vier wesentliche Ergebnisse herausgekommen.
Ergebnis eins ist die überarbeitete Blueprint Architecture, also die BPA 2025, die – und das ist wichtig – abwärtskompatibel ist mit dem, was es schon gibt. Es muss also niemand etablierte Systeme umstellen, aber sie erlaubt die Umsetzung von alternativen Szenarien, die sich insbesondere in den letzten Jahren im europäischen Kontext, zum Beispiel rund um die European Open Science Cloud (EOSC) oder bei Wallets, ergeben haben und vom Ansatz „Community first“ hin zur Alternative „Identity first“ geführt hat. Das bedeutet letztendlich, dass es immer eine zentrale Stelle (in Deutschland z.B. die Edu-ID) gibt, in welcher Verbindungen zu Forschungscommunities verwaltet werden.
Das Zweite ist eine neue Version des sogenannten Policy Development Kits. Das kommt aus dem Policy-Arbeitspaket und ist im Prinzip eine Sammlung von Dokumentenvorlagen, die von Forschungseinrichtungen verwendet werden können, um die Anforderungen an Richtlinien und Policies zu erfüllen. Das sind ganz praktisch gesagt Templates, in denen schon sehr viel vorausgefüllt ist und durch die man geführt wird – etwa beim Eintragen von Ansprechpartnern, Sicherheitskontakten oder bei der Frage, zu welchen Zwecken Daten verarbeitet werden. Neu ist auch eine interaktive Karte, mit der verortet wird, welche Policies von wem benötigt werden, sodass man filtern kann, welche für die eigene Infrastruktur relevant sind.
Das Dritte ist das AARC Handbook. Das ist eine Sammlung von einleitenden und erklärenden Artikeln, um auch Leuten, die mit dem Thema erst anfangen und gar nicht so technisch bewandert sind, zu erklären, was AARC tut und was die einzelnen Dokumente und Spezifikationen lösen möchten.
Und das Vierte ist ein Validation-Kit, mit dem man seine eigenen technischen Implementierungen auf die Kompatibilität mit AARC prüfen kann.

Spannend! Das sind ja wirklich echte Handreichungen, die man direkt für die praktische Umsetzung verwenden kann. War das das Ziel?

So würde ich das sehen. In technischen Projekten sitzen in den Arbeitsgruppen natürlich die technischen Experten, die damit jeden Tag arbeiten und seit Jahren in diesen Spezifikationen leben. Wenn dann jemand zum ersten Mal damit in Berührung kommt und diese sehr technischen Dokumente liest, ist immer die Frage, was der oder diejenige darunter versteht. Wir haben da eine gewisse Lernkurve hinter uns und gemerkt, dass teilweise ganz andere Dinge verstanden werden. Deshalb war das Ziel, insbesondere mit dem Handbook und dem Validator-Framework, die Ergebnisse möglichst einfach zugänglich zu machen und in möglichst einfachen Worten verständlich zu erklären, ohne viel Vorwissen vorauszusetzen.

Ich habe gelesen, dass in der überarbeiteten Architektur auch Entwicklungen wie tokenbasierte Zugriffe und digitale Wallets stärker berücksichtigt wurden. Wenn man sich anschaut, dass mit der EU Digital Identity Wallet gerade so eine europaweite Wallet-Infrastruktur entsteht, inwiefern war sowas für euch ein Treiber bei euren Architekturentscheidungen?

Genau. Die Herausforderung ist, dass man Wallets einerseits berücksichtigen muss, weil sie schon jetzt und verstärkt in den nächsten Jahren stark an Bedeutung gewinnen werden. Gleichzeitig gibt es in den Föderationen und Infrastrukturen, in denen wir arbeiten, noch viele Systeme, die vermutlich nicht einmal auf dem Stand der Blueprint Architecture von 2019 sind und teilweise noch ältere Technologien wie Zertifikate (statt SSO-Technologien wie SAML oder OIDC) oder Grid-Infrastrukturen nutzen. Man hat also eine sehr große Spannbreite an technischer Reife. Deshalb haben wir bei der Blueprint Architecture darauf geachtet, die konkrete technische Umsetzung offen zu lassen. Sie funktioniert mit älteren Technologien, schließt aber neue Ansätze wie Wallets nicht aus. Wir wollten nichts vorwegnehmen, aber die Voraussetzungen schaffen, damit Wallets sinnvoll integriert werden können. Dazu gab es auch ein eigenes Dokument, in dem wir analysiert haben, wie sich so eine komplexe Architekturlandschaft mit Wallets umsetzen lässt, und diese Ergebnisse sind in die neue BPA als „Identity first“ eingeflossen.

Die AARC Blueprint Architecture ist ja ein Referenzmodell, gleichzeitig sind viele Infrastrukturen historisch gewachsene Lösungen. Du bist selbst erfahrener Solutions Engineer und Product Owner bei DAASI International – mich würde deshalb deine Einschätzung interessieren: Wie schwierig ist es in der Praxis, solche bestehenden Systeme an ein gemeinsames Architekturmodell anzunähern?

Einerseits ist es keine Raketenwissenschaft, weil die zugrunde liegenden Technologien ja von den gängigen Produkten schon unterstützt werden. Zum Beispiel Shibboleth IdP – das ist bei DAASI nach wie vor die Software, mit der wir die meisten Authentifizierungsprojekte umsetzen oder auch unsere eigene Software-Lösung didmos.
Der Funktionsumfang vom Shibboleth IdP beinhaltet alles, was man zwingend braucht, um ein Projekt gemäß der AARC-BPA umzusetzen. Der Start ist mit den Softwareprodukten, die wir auch bei DAASI nutzen, also relativ einfach möglich.
Die Haupttechnologie, die in der AARC-BPA beschrieben wird, basiert darauf, dass man zwischen Service Providern und Identity Providern Proxys einführt und diese Proxy-Funktionalität kann z. B. von Shibboleth IdP oder didmos Auth erfüllt werden.
Die Herausforderung ist: Man hat eine ganze Menge an Service Providern – also den Diensten, auf die Nutzende zugreifen möchten – und eine ganze Menge an Identity Providern, also den Systemen, bei denen Nutzende sich authentifizieren, im einfachsten Fall mit Benutzername und Passwort, zunehmend auch mit Mehrfaktorauthentifizierung oder neuen Technologien wie Passkeys. Diese beiden Welten möchte man miteinander verbinden. Vor AARC hat man das einfach über Föderationen gemacht. In so einer Föderation gab es dann zum Beispiel 5000 Dienste und 1000 Identity Provider von den verschiedenen Hochschulen. Die Probleme, die dabei entstanden sind, hat man dann individuell an jedem einzelnen Dienst gelöst.
Die wesentliche Errungenschaft der AARC-BPA ist deshalb das Einführen eines Proxys. Man hat also auf einmal nicht mehr 5000 Dienste, an denen man jeweils separat ein Problem lösen muss, sondern setzt zwischen Dienste und Identity Provider einen oder mehrere Proxys. Die Entwicklung geht eher in Richtung mehrerer Proxys, weil man unterschiedliche Probleme an unterschiedlichen Stellen lösen möchte. So gibt es z. B. in AARC eine Proxyschicht „Identitätsmanagement“, welche in Deutschland von der DFN Edu-ID übernommen werden kann. Auch da ist DAASI International involviert und die Edu-ID sorgt dafür, dass Studierende und Forschende eine lebenslange Identität haben, die auch beim Einrichtungswechsel konstant bleibt. Ein anderer Proxy bildet dann das „Collaboration Management“ ab, in dem Gruppenmitgliedschaften und Berechtigungen innerhalb einer Forschungsinfrastruktur verwaltet werden können. Die Aufteilung auf zwei unterschiedliche Proxys ergibt Sinn, da die Edu-ID zentral, aber die Berechtigungen in der konkreten Community dezentral verwaltet werden sollen.
Der Aufbau einer einfachen BPA-konformen Infrastruktur ist also beherrschbar. Wir bieten z. B. im Rahmen der NFDI-AAI (Nationale Forschungsdateninfrastruktur) einen solchen Dienst „as a Service“ an. Wenn man aber Interoperabilität mit anderen Infrastrukturen schaffen möchte, hat man auf einmal viel mehr Anforderungen. Dann muss man aus dem ganzen Strauß an Dokumenten, die in AARC entstanden sind, nicht mehr nur die paar verpflichtenden Anforderungen erfüllen, sondern auch viele der Optionalen umsetzen. An der Stelle wird es dann zeitaufwendig und komplizierter. Mit dem nun entstandenen AARC Handbook hat das Projekt versucht, die Hürde noch weiter zu reduzieren.

Du hast vorhin die EOSC genannt, also die European Open Science Cloud. Dort ist ja schon einiges aus den Vorgängerprojekten von AARC eingeflossen. Was würdest du sagen: Wer profitiert am meisten von den Ergebnissen von AARC TREE, und wo werden wir die Auswirkungen als Erstes sehen?

Ja, die EOSC ist technisch sicherlich der Vorreiter. Dort werden die neuen Entwicklungen aus AARC in der Regel als Erstes implementiert, und sie ist natürlich auch die größte Umgebung, weil sehr viele Forschungsinfrastrukturen aus ganz Europa beteiligt sind und die Anforderungen entsprechend hoch sind. Insofern ist die EOSC sicherlich der Treiber hinter vielen dieser Entwicklungen, und ich gehe davon aus, dass dort neue Ergebnisse aus AARC TREE sehr schnell umgesetzt werden.

Wenn man auf Deutschland schaut, sind wir mit DAASI ja auch in der NFDI aktiv. Die ist gewissermaßen so etwas wie eine kleinere EOSC und offiziell eins der 13 sogenannten EOSC-Nodes. Sie ist ebenfalls gemäß AARC konzipiert und aufgebaut. Natürlich wird dort nicht jede Neuerung aus AARC TREE sofort umgesetzt, aber die wichtigen Ergebnisse – zum Beispiel in Richtung Interoperabilität mit der EOSC oder auch perspektivisch die Frage, wie man Wallets sinnvoll integrieren kann – werden jetzt wieder in die Diskussionen zurückgespielt, die wir etwa in der NFDI führen.

AARC TREE war ja ein großes, internationales Projekt mit vielen Partnern. Wie hast du die Zusammenarbeit mit diesen Partnern erlebt hast. Gab es typische EU-Projekt-Hürden?

Das „Kernteam“, welches seit dem ersten AARC-Projekt bis jetzt zu AARC TREE zusammenarbeitet, ist ein richtig eingespieltes Team geworden. Natürlich kommen immer wieder neue Leute mit neuen Perspektiven dazu, was für die Verbreitung und Akzeptanz der Lösungen essentiell ist, aber man sieht schon oft die gleichen Experten. Über die Jahre hat sich die Zusammenarbeit deshalb super eingespielt. Man kennt die Beteiligten, weiß, wo ihre Stärken liegen, und kennt die Prozesse. Das alles funktioniert inzwischen sehr gut.
Insofern ist die Arbeitsweise trotz der riesigen technischen Komplexität und der unterschiedlichen Anforderungen in einem internationalen Projekt sehr effizient. Gleichzeitig ist sie aber auch bereichernd und fruchtbar. Die Diskussionen, die man führt, sind wirklich aktuell am Puls der Zeit – und das macht die Arbeit daran total spannend und macht Spaß.

Das hört sich sehr vielversprechend an, und auch deshalb stellt sich natürlich die Frage: Wie geht es weiter? AARC TREE ist jetzt offiziell abgeschlossen, wird es ein neues Projekt geben mit dieser bewährten Truppe?

Für den Moment haben wir uns mit der bewährten Truppe darauf geeinigt, dass wir ohne neue Finanzierung weitermachen – einfach, um die neuen Entwicklungen weiter zu begleiten. Die Projektphase ist zwar vorbei, aber die Arbeit hört ja nie auf. Es gibt immer Themen, die diskutiert werden müssen, neue Fragestellungen und Probleme, die angegangen werden wollen.
Diese Gruppe – ich nenne sie mal das AARC-Architekturteam – bleibt deshalb bestehen. Wir werden uns als DAASI weiter beteiligen, um einerseits informiert zu bleiben und andererseits in den Bereichen, die uns betreffen und interessieren, aktiv mitzuarbeiten.
Natürlich gibt es immer auch Versuche, neues Funding zu bekommen, und Themen, die in einem möglichen AARC4-Projekt gut weitergeführt werden könnten. Ein Beispiel ist, wie man die Konzepte, die bisher auf Research und Collaboration, also auf große Forschungsinfrastrukturen, zugeschnitten wurden, auf andere Bereiche ausweiten kann. Ein oft genanntes Stichwort ist der Schulbereich. Schulen sind in ihrer Struktur Forschungsinfrastrukturen teilweise ähnlich – man kann sie föderieren, und sie brauchen vielleicht Zugriff auf gemeinsame Ressourcen oder Lernmanagement-Systeme.
Ein weiteres Thema könnten University Alliances sein, also kleinere Zusammenschlüsse von Universitäten, die in Europa immer wichtiger werden und eigene Herausforderungen mit sich bringen. Das sind alles Bereiche, die in einem AARC4-Projekt sinnvoll bearbeitet werden könnten. Wenn es in diese Richtung geht, sind wir natürlich gern wieder dabei.

Das ist ein sehr schönes Schlusswort. Vielen Dank für deine Zeit und die interessanten Einblicke in die Projektarbeit um AARC.

Weitere Informationen zu AARC TREE und den Projektergebnissen finden Sie auf der offiziellen AARC-Website sowie in den veröffentlichten Dokumentationen.