Identitäten und Vertrauen in Gaia-X

Föderative Informationssysteme

Föderative Informationssysteme stellen mehrere Informationsquellen zur Verfügung. Dabei werden die Daten der einzelnen Informationsquellen nicht kopiert.[5] Nehmen wir an, wir hätten ein Informationssystem, welches Daten über den Verkehr bereitstellt. Die Daten über das Verkehrsaufkommen werden aus mehreren eigenständigen Informationsquellen bezogen. Unser Informationssystem fragt die Daten aus den Informationsquellen ab und stellt diese zur Verfügung. Dabei werden die abgefragten Daten der Informationsquellen nicht in unserem Informationssystem zwischengespeichert. Im Gaia-X Umfeld bildet z.B. der Mobility-Bereich eine solche Föderation. Jeder Teilnehmer dieser Föderation kann Daten konsumieren, bereitstellen oder auch Services anbieten, die dem Mobility-Bereich zuzuordnen sind. Im Moment befindet sich die Mobility- und viele andere Föderationen im Aufbau.

Föderationen in Gaia-X

Als Föderation in Gaia-X bezeichnet man eine Gruppe von Teilnehmern, die sich einem bestimmten Use-Case widmen. Die Teilnehmer müssen nicht unbedingt aus der gleichen Branche kommen. Sie können aus verschiedenen Industrien kooperieren und somit Ökosysteme bilden, die aufeinander aufbauen oder andere Ökosysteme erweitern. Beispielsweise könnte die Mobility- und Insurance-Federation sich so zusammenschließen. Innerhalb einer Föderation nimmt ein Teilnehmer mindestens eine der folgenden Rollen ein: Provider, Consumer, Federator. Als Teilnehmer werden natürliche Personen, Services oder Unternehmen bezeichnet. Der Provider stellt Informationsquellen zur Verfügung. Diese werden vom Consumer im Gaia-X Ökosystem verwendet, um digitale Angebote für den Endkunden bereit zu stellen. An der Stelle sei erwähnt, dass Endkunden oder Otto Normalverbraucher kein Teil des Gaia-X Ökosystems sind.

Innerhalb einer Föderation muss mindestens ein Teilnehmer die Rolle des Federators übernehmen. Der Federator ist für die Föderation und für die Federation Services verantwortlich. Die Federation Services bilden die Minimalanforderung an eine Föderation. Sie werden für die operative Inbetriebnahme benötigt und ermöglichen die Kommunikation aller Teilnehmer (Consumer/Producer). Dabei muss jeder Teilnehmer eine Self Description besitzen. Diese enthält Informationen über den Teilnehmer in einem standardisierten Format. Teilnehmer können ihre Integrität anhand der Self Description gegenseitig verifizieren. Zudem hat jede Föderation einen Service Catalogue. Eine Liste, in der alle Services dieser Föderation gelistet sind. Dabei ist es egal, in welcher Cloud sich die jeweiligen Services befinden.[4][1]

Federation Services

Um eine Föderation in Betrieb zu nehmen, muss der Federator die Federation Services Implementieren. Diese gelten, wie oben bereits erwähnt, als Mindestanforderung. Die Federation Services werden von der AISBL als Toolbox bereitgestellt und von der Gaia-X Community als Open Source Software entwickelt. Der Federator sollte diese auf die Bedürfnisse und Anforderungen der Föderation erweitern. Die Kernfunktionalitäten der Federation Services dürfen allerdings nicht geändert werden. Frei nach dem Open/Closed-Principle bieten diese generische Funktionalitäten für jegliche Use-Cases. Das ist wichtig, denn beispielsweise hat die Automotive-Föderation ganz andere Anforderungen, als die Insurance-Föderation. Aufgrund der Erweiterungen des Federators hat nicht jede Föderation die gleichen Ferderation Services.[4]

Abbildung 1: Federation Services und die Verbindung zwischen Data- und Infrastructure Ecosystem [1]

Abbildung 1 gibt einen groben Überblick über die Federation Services und wie diese das Data Ecosystem und Infrastructure Ecosystem verbinden. Das Infrastruktur-Ökosystem besteht aus Services, die den Transfer, Speicherung und Prozessierung von Daten gewährleisten. Diese Ressourcen können sich in verschiedenen Clouds befinden. Das Daten-Ökosystem besteht aus Services, die diese Daten bereitstellen oder neue Daten an das Infrastructure Ecosystem weitergeben. Diese beiden Ecosystems bauen aufeinander auf und ergänzen einander. Im Moment befinden sich folgenden Federation Services in Entwicklung: Identity and Trust, Federated Catalogue, Data Sovereignty, Compliance. Interessant ist hier der Identity & Trust Service.[4]

Identity & Trust in Gaia-X

Jede Identität, die im Gaia-X Ökosystem partizipieren will, besteht aus einem oder mehreren einzigartigen Identifiern und einer Liste aus zugehörigen Attributen. Diese Identität ist Teil der Self-Description. Bevorzugt setzt Gaia-X auf den DID-Standard, da dieser einzigartige Identifier ermöglicht. Gaia-X verwendet ausschließlich vorhandene Identitäten. Externe Identity-Provider sind für die Bereitstellung und Verwaltung verantwortlich. Vertrauen zwischen den Identitäten wird durch kryptografische Verifizierung sichergestellt. Diese Aufgabe übernimmt das Federated Trust Model. Dabei wird durch Proof of Identity garantiert, dass jeder beteiligte Teilnehmer der ist, der er vorgibt zu sein. Die Self-Description ist im JSON-LD und W3C Verifiable Credential Format aufgebaut. Neben den Identifiern beinhaltet diese öffentlich Verfügbare Informationen und (falls vorhanden) Information über die angebotenen Services. Abbildung 2 zeigt beispielhaft eine Self-Description eines Services.[2] Abbildung 2: Auszug einer Self-Description [2]

Der Lebenszyklus einer Identität in Gaia-X ist wie folgt: Bei dem Onboarding einer neuen Identität in das Gaia-X Ökosystem wird die bereitgestellte Self-Description des Teilnehmers validiert und von der akkreditierten Konformitätsbewertungsstelle signiert (Proof of Identity). Jeder Teilnehmer muss das Onboarding einmal durchlaufen. Sollten Änderungen an der Self-Description vorgenommen werden, die sich auf das Vertrauen beziehen, werden diese in einer neuen Version validiert und signiert. Änderungen einer bereits vertrauenswürdigen Identität sind in der M

aintaining-Phase verordnet. Falls ein Teilnehmer nicht mehr im Gaia-X Ökosystems partizipieren soll, wird er durch das Offboarding entfernt. Das geschieht durch expliziten Vertrauensentzug der AISBL oder durch einen Offboarding-Request. Ein Offboarding-Request wird z.B. dann erstellt, wenn ein Microservice in einer Föderation nicht mehr benötigt und heruntergefahren wird. Der Berechtigungsnachweis der Identität wird dabei zurückgezogen und sie ist somit nicht mehr vertrauenswürdig.[2][1]

Hybrider IAM Ansatz

Bezüglich Identity & Access Management setzt Gaia-X auf einen hybriden IAM Ansatz. Hierzu findet man in den Quellen unterschiedliche Äußerungen.  Im Architecture Document ist die Rede von einem zweistufigen Modell. Im ersten Schritt stellen ausgewählte Identity Systeme die gegenseitige Identifizierung und das Vertrauen zwischen den Teilnehmern her. Danach verwenden die Teilnehmer Technologien wie Open ID Connect für die weitere Kommunikation. Allerdings unter der Prämisse, dass sich beide Parteien vertrauen. In der IAM Framework Veröffentlichung der IAM Community von Gaia-X, wird dieser Ansatz anders beschrieben. Hierbei könne der Teilnehmer wählen, ob er den föderierten oder dezentralen Ansatz verwenden möchte. Bei dem föderierten Ansatz befinden sich der Identity Provider in der Föderation, hingegen wird bei dem dezentralen Ansatz auf Self Sovereign Identites gesetzt. [3][1]

Die Zugriffsrechte vergibt die Föderation. Diese können mit dem Federated Catalouge verlinkt werden um administrative Resourcen zu schützen. Die zugewiesene Rolle zu einer Identität wird in der Self-Description gespeichert und ist ein optionales Attribut. [3]

Fazit

Gaia-X ist noch spürbar in den Kinderschuhen. Teils wegen schwammiger Aussagen in den Whitepapers, teils wegen fehlender Einsicht in den aktuellen Implementierungsstand der Federation Services. Diese werden zwar als Open-Source beworben, aber ohne Mitglied in der Gaia-X Community zu sein, hat man nur eingeschränkten Zugriff auf die Gitlab-Projekte. Allerdings gibt es bereits eine Demo über eine minimale Gaia-X Application. Diese gibt schon Mal erste Anreize, wo die Reise hingeht.

Quellen:

1. https://www.gaia-x.eu/sites/default/files/2021-10/Gaia-X_Architecture_Document_2109.pdf
2. https://www.gxfs.de/wp-content/uploads/2021/08/annex_GX_IDM_AO.pdf
3. https://community.gaia-x.eu/s/P23ZJNLyjf7n7Zp/download?path=/Releases&files=GAIA-X%20IAM%20Framework%20v1.2.pdf
4. https://gaia-x.eu/sites/default/files/2022-01/Gaia-X_Federation_Services_White_Paper_1_December_2021.pdf
5. https://de.wikipedia.org/wiki/F%C3%B6deriertes_Informationssystem