Hochschul-Föderation — unifederation.eu

Warum überhaupt eine Föderation

Drei Probleme, die jede App sonst selbst lösen müsste

Eine Studentin ist an der TU Graz eingeschrieben und besucht Kurse an der Universität Graz. Eine Anwendung, die ihre Daten über beide Hochschulen hinweg zusammenführen soll, stößt auf immer dieselben drei Hürden.

01

Identität

An jeder Hochschule ein eigenes Konto. Es gibt keine gemeinsame Kennung, die eine Anwendung voraussetzen dürfte.

02

Autorisierung

Zugriff braucht ein Token, das die jeweilige Hochschule ausgestellt hat. Nur sie kann entscheiden, wer ihre Daten sehen darf.

03

Vielfalt

Andere Schnittstellen, andere Basis-Adressen, andere Systeme — je Hochschule neu. Die Föderation löst das einmal zentral.

Die Föderation stellt keine eigenen Zugriffsrechte aus. Jeder Zugriff auf Hochschuldaten erfolgt mit einem Token, das die betreffende Hochschule selbst für diese Person ausgestellt hat. Über den Umfang entscheidet allein die Hochschule.

Das Grundprinzip in einem Satz

Wer ist diese Person?

Entscheidet die Heimat-Hochschule — beim Login an ihrem eigenen System.

Darf sie diese Daten sehen?

Entscheidet die jeweilige Hochschule — über Scopes und Rollen im Token.

Welche Hochschulen sind meine?

Entscheidet die Person selbst — Verknüpfen und Trennen im Hub.

Wer administriert die Föderation?

Entscheidet die Föderation. Rollen aus Hochschul-Tokens gelangen nie hierher.

So funktioniert es

Vier Schritte — und die Anwendung fragt nur noch einmal

1
Hochschule wählen

Das Verzeichnis ist durchsuchbar und zeigt Namen und Logos. Die Auswahl („WAYF“) macht die Anwendung, nicht der Login-Server.
2
Am eigenen System anmelden

Die Anmeldung passiert bei der Hochschule. Zugangsdaten bleiben dort — die Föderation sieht sie nie.
3
Weitere Hochschulen verknüpfen

Jede weitere Hochschule kommt per Login dazu und hängt am selben Föderationskonto. Trennen geht jederzeit — mit einem Klick.
4
Eine Anfrage, alle Hochschulen

Die Anwendung ruft einen Endpunkt auf und erhält eine Liste — je Eintrag mit der Hochschule, aus der er stammt.

Die Bausteine im Zusammenspiel

Durchgezogen: Föderations-Infrastruktur. Gestrichelt: Systeme der Hochschule.

Der Hub erzeugt nie ein Hochschul-Token. Er liest das gespeicherte Token dort, wo es beim Login der Person hinterlegt wurde, und reicht es an eine registrierte Anwendung weiter.

Bausteine

Vier Teile, klar getrennte Aufgaben

Die Identitätsarbeit macht Keycloak. Die Mehrwertschicht darüber macht der Hub. Die fachliche Bündelung macht die API. Und das Verzeichnis lebt in git — versioniert, nachvollziehbar, reviewbar.

Federation Hub hub.unifederation.eu

Hochschulverzeichnis, Hochschulauswahl beim Login, „Meine Hochschulen“, Token-Fassade für Anwendungen und die Administration. Die Datenbank enthält ausschließlich Konfiguration — keine personenbezogenen Nutzerdaten.

Verzeichnis aus git, täglicher Abgleich
Verknüpfen und Trennen durch die Person
Token-Fassade mit zwei Schranken je Zugriff

Konzept lesen

Federation API api.unifederation.eu

Aus n Aufrufen mit Fehlerbehandlung wird einer: Die API holt Tenants und Tokens, ruft die Hochschulen parallel auf und liefert eine Liste plus Teilfehler. Ohne Datenbank — Fachdaten werden durchgeleitet, nicht gespeichert.

Parallel auf virtuellen Threads, 15 s Gesamtbudget
Teilfehler nach RFC 9457 statt leerer Seite
Erlaubte Zieladressen, HTTPS zwingend

Konzept lesen

Keycloak Realm federation

Ein Konto je Person, jede Hochschule als gebrokerter OIDC Identity Provider, die gespeicherten Hochschul-Tokens und die Sitzungen. Die Föderation liest dort nur — verändern kann sie im Realm nichts.

Ein technisches Konto kann keine fremden Tokens lesen
Leserechte des Admin-Zugangs bewusst minimal

Verzeichnis federation/meta

Zwei Dateien in git: partners.json sagt, wer existiert — tenant-apis.json sagt, wer welche Schnittstelle wo anbietet. Jede Änderung hat einen Autor, ein Datum und eine Begründung.

Neue Einträge entstehen deaktiviert
Scharfschalten ist ein eigener, bewusster Schritt

Repository ansehen

Für Hochschulen

Mitmachen heißt: Contract erfüllen, Eintrag pflegen

Wir bauen keinen Adapter je Campus-System. Föderierte Schnittstellen sind Contracts: Die Föderation veröffentlicht sie, die Hochschule erfüllt sie. Damit bleibt der Server klein — und die Föderation wächst ohne Codeänderung.

Contracts abfragen: GET /api/apis
OpenAPI-Dokument des Contracts holen
Implementierung generieren und erfüllen
Eintrag in tenant-apis.json
Abgleich läuft — die Hochschule ist Teil der Aggregation

Kein Schritt davon erfordert eine Änderung am Code der Föderation. Vier Schritte liegen bei der Hochschule, einer ist Datenpflege.

Beitritt schaltet nichts frei

Der Tenant entsteht deaktiviert und wird erst aktiv, wenn Konfiguration, Test und die ausdrückliche Freigabe vorliegen.

Ein Dokument, zwei Seiten

Die Beitrittserklärung verweist auf Ordnung und Anlagen. Weitere Hochschulen treten demselben Vertragswerk bei — niemand muss nachverhandeln.

Unentgeltlich

Die Teilnahme kostet nichts und setzt keine Vereinsmitgliedschaft voraus. Ein Verzeichniseintrag ohne Aktivierung ist ebenfalls möglich.

Für Anwendungen

Drei Endpunkte am Hub — oder ein Aufruf an die API

Der öffentliche Vertrag hat sein eigenes OpenAPI-Dokument. Anwendungen generieren ihre Clients ausschließlich daraus; die interne Schnittstelle der Weboberfläche ist keine Zusage.

Endpunkt	Scope	Antwort
`GET /api/public/tenants`	`federation:tenants:read`	Die für diese Anwendung freigegebenen Hochschulen — samt API-Routing
`GET /api/public/me/links`	`federation:links:read`	Je Hochschule: verknüpft? Token verfügbar?
`GET /api/public/me/tenants/{tenantId}/token`	`federation:token:read`	Die Token-Fassade: das Hochschul-Token der Person

Token holen

GET /api/public/me/tenants/tugraz/token
Authorization: Bearer <Token der Person>

200 OK
{
  "accessToken": "eyJhbGciOi…",
  "tokenType":   "Bearer",
  "expiresIn":   285
}

Aggregiert über alle Hochschulen

GET /api/me/user-info      → 200 OK
{
  "list": [
    { "tenantId": "community-dev", "name": "Maria Beispiel" }
  ],
  "problems": [
    { "tenantId": "tugraz-coreview", "status": 504,
      "detail": "tenant did not respond within the budget" }
  ]
}

Zwei Schranken je Zugriff

Keycloak entscheidet über den Scope, der Hub über Registrierung und Freigabeliste. Beide müssen passieren.

Ohne Freigabe kein Tenant

Eine Anwendung ohne Eintrag in der Freigabeliste sieht keine einzige Hochschule. Das ist die sichere Voreinstellung.

Fehler sind Teil des Vertrags

404 heißt: die Administration muss handeln. 409 heißt: die Person kann es selbst lösen — die Antwort nennt gleich den nötigen Aufruf.

Voraussetzung: eine aktive Sitzung der Person. Das Token wird serverseitig weitergereicht — ein Zugriff ohne anwesende Person findet nicht statt.

Recht & Datenschutz

Für Datenschutzbeauftragte und Rechtsabteilungen

Die Föderation umfasst Verarbeitungen mit unterschiedlicher Rollenverteilung. Genau das wird aufgeschlüsselt, statt es unter einen einzigen Vertragstyp zu zwingen.

Verarbeitung	Community (Betreiberin)	Hochschule
Betrieb des Föderations-Keycloak	eigenständig verantwortlich	eigenständig verantwortlich für Authentifizierung und Attributübermittlung
Durchleitung fachlicher Daten	Auftragsverarbeiterin (Art. 28)	Verantwortliche
Föderationsverzeichnis (Metadaten)	Verantwortliche	mitwirkend

Bewusst keine gemeinsame Verantwortlichkeit

Kein Art. 26 — und damit keine gesamtschuldnerische Haftung. Jede Seite haftet für ihren eigenen Bereich. Das Modell folgt dem, was im Hochschul-Föderationsumfeld etabliert ist.

Standardvertragsklauseln, unverändert

Für die Auftragsverarbeitung gelten die Klauseln der Europäischen Kommission (Durchführungsbeschluss (EU) 2021/915) unverändert. Über den Wortlaut ist nicht zu verhandeln — auszufüllen sind nur die Anhänge, und die liegen ausgefüllt vor.

Ort	Was dort liegt	Dauer
Föderations-Keycloak	Ein Konto je Person, die Verknüpfungen zu den Hochschulen, die gespeicherten Hochschul-Tokens	bis zum Trennen bzw. zur Kontolöschung
Federation Hub (Datenbank)	keine personenbezogenen Nutzerdaten — Verzeichnis, Routing, Anwendungsregistrierung	—
Federation API	keine Datenbank; Fachdaten werden durchgeleitet, Zwischenspeicher nur im Arbeitsspeicher	Dauer der Anfrage bzw. 10 Minuten
Protokolle	Kennung der Hochschule, Ziel-Adresse, HTTP-Status — keine Inhalte, keine Tokens	nach Betriebsvorgabe

Was die Konstruktion entlastet

Kein Fachdatenspeicher bei der Community — die Federation API hat keine Datenbank.
Jeder Zugriff mit einem Token des Quellsystems — die Autorisierungsentscheidung bleibt bei der Hochschule.
Verknüpfen und Trennen sind Handlungen der Person, nicht der Föderation.
Kein Zugriff ohne aktive Nutzersitzung — technische Konten können keine fremden Tokens lesen.
Eine Anwendung ohne ausdrückliche Freigabe sieht keinen Tenant deiner Hochschule.
Kein KI-Einsatz im beschriebenen Stand — die Föderation leistet Identitäts- und Datenföderation.

Transparenz

Was wir offen benennen

Diese Punkte stehen in den Vertragsunterlagen und in der technischen Dokumentation — nicht nur hier. Wer eine Föderation bewerten soll, braucht die Lücken genauso wie die Stärken.

Pilotbetrieb

Keine Verfügbarkeitszusage. Der Betriebszustand ist ausdrücklich als Pilot festgehalten.

Trennen widerruft nicht am Quellsystem

Verknüpfung und gespeicherte Tokens werden gelöscht. Ein bereits ausgegebenes Token bleibt bis zu seinem Ablauf gültig — ein sofortiger Widerruf ist nur durch die Hochschule möglich.

Einwilligungs- und Transparenzdialoge

In Arbeit. Die Verarbeitung beruht nicht auf Einwilligung, sondern auf der öffentlichen Aufgabe.

Zugriff ohne aktive Nutzersitzung

Findet nicht statt. Er würde erst nach Ankündigung und Zustimmung aktiviert.

Sicherungen

Sie enthalten Konten, Verknüpfungen und Tokens und werden Ende-zu-Ende verschlüsselt; der Schlüssel liegt nicht am Speicherort. Intervall und Erprobung sind noch zu dokumentieren.

Nachweisbarkeit von Zugriffen

Die Ereignisprotokollierung des Realms ist noch nicht aktiviert. Damit ist heute nicht belegbar, wann für wen welches Hochschul-Token ausgegeben wurde.

Häufige Fragen

Kurz beantwortet

Sieht die Föderation mein Passwort?

Nein. Die Anmeldung passiert am System deiner Hochschule. Die Föderation erhält das Ergebnis der Anmeldung, nicht deine Zugangsdaten.

Erfährt meine Hochschule, an welchen anderen Hochschulen ich bin?

Nein. Dieses Verknüpfungswissen entsteht erst in der Föderation und liegt ausschließlich dort. Keine der beteiligten Hochschulen erhält es.

Kann die Föderation Rechte an meiner Hochschule verschaffen?

Nein. Sie stellt keine eigenen Rechte aus. Wer an einer Hochschule Administrator ist, ist damit auch nicht Administrator der Föderation — und umgekehrt.

Was passiert, wenn eine Hochschule gerade nicht antwortet?

Die Antwort kippt nicht. Jede abgefragte Hochschule erscheint genau einmal — mit Daten oder mit einem Problemeintrag. Eine Anwendung kann so „3 von 4 geladen“ anzeigen.

Ist SAML oder eduGAIN möglich?

Heute bewusst ausgeklammert. Technisch ließe sich SAML brokern — die Tür bleibt für Hochschulen mit Shibboleth offen.

Steckt KI dahinter?

Im beschriebenen Stand nicht. Hub und API leisten Identitäts- und Datenföderation; der AI-Act ist darauf nicht anwendbar.

Mitmachen

Interesse an einer Teilnahme?

Der Einstieg beginnt mit einem Gespräch — nicht mit einer Vertragsprüfung. Ein Verzeichniseintrag ohne Aktivierung ist jederzeit möglich, und für den Start empfehlen wir ausdrücklich den kleineren Datenumfang: zunächst ohne langlebigen Grant.

CAMPUSonline Community Repositories ansehen

Kontaktstellen

Kontakt: Lucas Reeh
Technik: Lucas Reeh
Datenschutz: Datenschutzerklärung

Vorläufige Kontaktstellen, bis die Betreiberin die offiziellen Adressen benennt.

Die vollständige Systemdokumentation ist öffentlich — einschließlich der datenschutzrelevanten Sicht und der offenen Punkte.