Hintergrund

Odysseus ist ein an der Universität Oldenburg entwickeltes Datenstrommanagementsystem. Es ermöglicht die kontinuierliche Verarbeitung von Datenströmen und kann Anfragen auf mehrere miteinander verbundene Odysseus-Knoten verteilen. Weitere Informationen zum System sind unter https://odysseus.uni-oldenburg.de verfügbar.

Odysseus besitzt derzeit ein integriertes Benutzermanagement. Benutzerinnen und Benutzer melden sich an einem Odysseus-Knoten an und erhalten abhängig von ihren Rollen und Berechtigungen Zugriff auf Anfragen, Dienste und administrative Funktionen.

In einer verteilten Umgebung reicht eine rein lokale Authentifizierung jedoch nicht aus. Ein Odysseus-Knoten kann im Auftrag eines Benutzers Operationen auf einem anderen Knoten ausführen, beispielsweise:

• eine Teilanfrage übertragen,
• eine Anfrage starten oder stoppen,
• Ergebnisse abrufen,
• Informationen über verfügbare Dienste ermitteln,
• eine verteilte Anfrage entfernen.

Der entfernte Knoten kennt dabei die ursprüngliche Identität und die Berechtigungen des Benutzers bislang nicht zuverlässig. Daher werden solche Knotenverbindungen in der Praxis häufig mit administrativen Zugangsdaten eingerichtet. Dies führt dazu, dass ein entfernter Aufruf wesentlich mehr Berechtigungen besitzt, als für die jeweilige Operation benötigt werden.

Dieses Vorgehen widerspricht dem Prinzip der minimal erforderlichen Berechtigungen. Außerdem kann eine ausgeführte Aktion nicht zuverlässig dem ursprünglich verantwortlichen Benutzer zugeordnet werden.

Ziel der Arbeit

Ziel der Bachelorarbeit ist die Konzeption und prototypische Implementierung einer tokenbasierten Authentifizierung und Autorisierung für verteilte Odysseus-Umgebungen.

Als Referenzimplementierung für die zentrale Benutzerverwaltung, Authentifizierung und Tokenausstellung soll Keycloak untersucht und eingesetzt werden. Die Odysseus-seitige Lösung soll möglichst auf standardisierten Verfahren wie OpenID Connect, OAuth 2.0 und signierten JWT Access Tokens basieren, damit sie nicht unnötig stark an Keycloak gebunden ist.

Wenn ein Odysseus-Knoten im Auftrag eines Benutzers auf einen anderen Knoten zugreift, sollen dessen Identität und die für die konkrete Operation erforderlichen Berechtigungen sicher weitergegeben werden. Der entfernte Knoten soll das Token selbstständig prüfen und die Operation nur dann ausführen, wenn die enthaltenen Berechtigungen ausreichen.

Dabei sollen weder Benutzerpasswörter zwischen den Knoten übertragen noch dauerhafte Administratorkonten für die Knotenkommunikation verwendet werden.

Die zentrale Forschungsfrage lautet:

Wie können Identität und Berechtigungen eines Benutzers mithilfe eines zentralen Identity Providers sicher zwischen mehreren Odysseus-Knoten weitergegeben und überprüft werden, ohne pauschale Administratorrechte zu verwenden?

Grundidee

Keycloak übernimmt als zentraler Identity Provider beziehungsweise Authorization Server insbesondere folgende Aufgaben:

• Verwaltung von Benutzerinnen und Benutzern,
• Authentifizierung über OpenID Connect,
• Verwaltung von Rollen und Berechtigungen,
• Ausstellung kurzlebiger Access Tokens,
• Verwaltung technischer Clients und Service Accounts,
• Bereitstellung öffentlicher Signaturschlüssel,
• Austausch eines Tokens gegen ein Token für einen anderen Zielknoten.

Die Odysseus-Knoten agieren als geschützte Resource Server. Sie validieren eingehende Access Tokens und prüfen anschließend, ob die darin enthaltenen Rollen oder Scopes für die gewünschte Operation ausreichen.

Ein beispielhafter Ablauf ist:

1. Ein Benutzer meldet sich über das WebStudio bei Keycloak an.
2. Keycloak stellt dem WebStudio ein kurzlebiges Access Token aus.
3. Das WebStudio übermittelt das Token bei einer Anfrage an einen Odysseus-Knoten.
4. Der Knoten validiert Signatur, Aussteller, Empfänger und Gültigkeitsdauer.
5. Die Anfrage soll teilweise auf einem anderen Odysseus-Knoten ausgeführt werden.
6. Der lokale Knoten reicht das vorhandene Token weiter oder tauscht es gegen ein eingeschränktes Token für den Zielknoten aus.
7. Der Zielknoten validiert das Token und prüft die benötigten Berechtigungen.
8. Die Operation wird unter der Identität des ursprünglichen Benutzers ausgeführt und protokolliert.

Authentifizierung und Autorisierung

Die Arbeit soll klar zwischen Authentifizierung und Autorisierung unterscheiden.

Authentifizierung

Die Authentifizierung stellt fest, welche Person oder welcher Dienst eine Anfrage stellt. Diese Aufgabe soll im Prototyp grundsätzlich durch Keycloak übernommen werden.

Das WebStudio verwendet OpenID Connect für die Anmeldung. Für Aufrufe der Odysseus-REST-Schnittstellen werden Access Tokens verwendet. OpenID-Connect-ID-Tokens sollen nicht als Zugriffstoken für die REST-Schnittstellen verwendet werden.

Autorisierung

Die Autorisierung entscheidet, ob die identifizierte Person oder der Dienst eine konkrete Aktion auf einer bestimmten Odysseus-Ressource ausführen darf.

Ein gültiges Access Token allein gewährt daher nicht automatisch Zugriff auf alle Funktionen. Der jeweilige Odysseus-Knoten muss zusätzlich prüfen:

• ob das Token für diesen Knoten bestimmt ist,
• ob die benötigte Rolle oder der benötigte Scope vorhanden ist,
• ob der Benutzer auf die konkrete Ressource zugreifen darf,
• ob eine delegierte Operation zulässig ist.

Keycloak liefert Identität und Berechtigungsmerkmale. Die fachliche Auswertung dieser Merkmale bleibt Aufgabe von Odysseus.

Direkte Tokenweitergabe und Token Exchange

Im Rahmen der Arbeit sollen zwei Ansätze untersucht und miteinander verglichen werden.

Direkte Tokenweitergabe

Knoten A reicht das vom WebStudio erhaltene Access Token an Knoten B weiter.

Dieser Ansatz ist vergleichsweise einfach. Er setzt jedoch voraus, dass das Token auch für Knoten B gültig ist. Außerdem kann es mehr Berechtigungen und Empfänger enthalten, als für den konkreten Aufruf erforderlich sind.

Token Exchange

Knoten A tauscht das vorhandene Access Token bei Keycloak gegen ein neues Token aus, das für Knoten B und die benötigte Operation ausgestellt wird.

Ein solches Token kann beispielsweise folgende Eigenschaften besitzen:

audience = odysseus-node-b

scopes   = queries:create queries:start

lifetime = 60 Sekunden

Das ursprüngliche Token könnte dagegen zusätzliche Rechte enthalten:

queries:create

queries:start

queries:stop

queries:delete

users:manage

Der Token Exchange ermöglicht somit eine Einschränkung des Empfängers, der Gültigkeitsdauer und der weitergegebenen Berechtigungen. Keycloak unterstützt dafür einen standardisierten Token-Exchange-Mechanismus.

Die prototypische Umsetzung soll nach Möglichkeit die direkte Tokenweitergabe als einfache Ausgangslösung und Token Exchange als abgesicherte Variante betrachten.

Aufgabenstellung

Im Rahmen der Arbeit sollen insbesondere folgende Aufgaben bearbeitet werden:

• Analyse des bestehenden Odysseus-Benutzermanagements
• Untersuchung der Kommunikation zwischen verteilten Odysseus-Knoten
• Identifikation der Stellen, an denen administrative Zugangsdaten verwendet werden
• Analyse von OpenID Connect, OAuth 2.0, JWT und Token Exchange
• Einrichtung einer geeigneten Keycloak-Testumgebung
• Definition eines Keycloak-Realm- und Client-Modells für WebStudio und Odysseus-Knoten
• Entwicklung eines Rollen- beziehungsweise Scope-Modells
• Anbindung des WebStudios an Keycloak
• Implementierung der JWT-Validierung in ausgewählten Odysseus-REST-Schnittstellen
• Abbildung der Tokeninformationen auf den Odysseus-Sicherheitskontext
• Weitergabe der Benutzeridentität bei ausgewählten verteilten Operationen
• prototypische Implementierung beziehungsweise Integration des Token Exchange
• Durchsetzung der delegierten Berechtigungen auf dem Zielknoten
• Protokollierung verteilter Aktionen unter der ursprünglichen Benutzeridentität
• Entwicklung automatisierter Funktions- und Sicherheitstests
• Evaluation des Ansatzes in einer Umgebung mit mehreren Odysseus-Knoten
• Entwicklung eines möglichen Migrationspfads vom integrierten Benutzermanagement

Rollen und Berechtigungen

Im Rahmen der Arbeit soll ein geeignetes Berechtigungsmodell für ausgewählte Operationen entwickelt werden.

Mögliche Scopes sind beispielsweise:

queries:read

queries:create

queries:start

queries:stop

queries:delete

results:read

services:read

nodes:read

nodes:delegate

Neben globalen Rollen soll untersucht werden, inwieweit Berechtigungen an konkrete Ressourcen gebunden werden müssen. Ein Benutzer könnte beispielsweise berechtigt sein:

• nur eigene Anfragen zu lesen,
• nur eigene Anfragen zu starten und zu stoppen,
• Ergebnisse bestimmter Anfragen abzurufen,
• Anfragen nur auf ausgewählten Knoten auszuführen,
• keine administrativen Benutzeroperationen auszuführen.

Die Arbeit soll sich auf eine überschaubare Auswahl von Operationen aus dem Lebenszyklus einer verteilten Anfrage konzentrieren.

Benutzer- und Dienstidentitäten

In einer verteilten Umgebung müssen zwei Arten von Identitäten unterschieden werden:

• die Identität des Benutzers, in dessen Auftrag eine Operation ausgeführt wird,
• die technische Identität des aufrufenden Odysseus-Knotens.

Keycloak kann Odysseus-Knoten als eigene Clients mit Service Accounts verwalten. Damit kann ein Knoten technische Operationen unter seiner eigenen Identität ausführen.

Bei einer delegierten Benutzeroperation soll der Zielknoten dagegen nachvollziehen können:

• welcher Benutzer die Aktion ursprünglich ausgelöst hat,
• welcher Odysseus-Knoten die Anfrage technisch übermittelt hat,
• welche Berechtigungen delegiert wurden,
• ob der aufrufende Knoten zur Delegation berechtigt ist.

Diese Trennung ist insbesondere für Autorisierungsentscheidungen, Audit-Logs und die Erkennung einer unzulässigen Rechteausweitung relevant.

Tokenvalidierung auf den Odysseus-Knoten

Die Odysseus-Knoten sollen Access Tokens lokal anhand der von Keycloak veröffentlichten öffentlichen Schlüssel validieren können. Dadurch ist nicht für jeden REST-Aufruf eine synchrone Anfrage an Keycloak erforderlich.

Mindestens folgende Eigenschaften sollen geprüft werden:

• kryptografische Signatur,
• erwarteter Aussteller,
• Gültigkeitsbeginn und Ablaufzeit,
• vorgesehener Empfänger beziehungsweise Audience,
• erlaubter Client,
• benötigte Rollen oder Scopes,
• zulässige Delegation.

Die Validierung kann beispielsweise durch einen Filter der REST-Schnittstelle erfolgen. Nach erfolgreicher Prüfung wird aus den Tokeninformationen ein Odysseus-Sicherheitskontext erzeugt, der von den einzelnen Endpunkten für die Autorisierung verwendet wird.

Keycloak-Konfiguration

Für den Prototyp soll ein Keycloak-Realm mit mindestens folgenden Clients aufgebaut werden:

• WebStudio als Benutzer-Client,
• erster Odysseus-Knoten,
• zweiter Odysseus-Knoten.

Dabei soll untersucht werden:

• ob jeder Odysseus-Knoten eine eigene Audience benötigt,
• welche Clients vertraulich sein müssen,
• wie Service Accounts für technische Aufrufe verwendet werden,
• wie Rollen und Scopes abgebildet werden,
• welche Clients Token austauschen dürfen,
• wie Tokenlaufzeiten konfiguriert werden,
• wie öffentliche Signaturschlüssel abgerufen und aktualisiert werden.

Die Konfiguration soll reproduzierbar dokumentiert und nach Möglichkeit automatisiert bereitgestellt werden.

Sicherheits- und Vertrauensmodell

Zu Beginn der Arbeit soll ein Bedrohungs- und Vertrauensmodell entwickelt werden. Dieses soll unter anderem folgende Fragen beantworten:

• Welchen Keycloak-Instanzen vertraut ein Odysseus-Knoten?
• Wie werden Odysseus-Knoten eindeutig identifiziert?
• Welche Knoten dürfen im Namen eines Benutzers handeln?
• Welche Berechtigungen dürfen weitergegeben werden?
• Darf ein Knoten Berechtigungen weiter einschränken?
• Wie wird eine Ausweitung der Berechtigungen verhindert?
• Wie wird ein Token an einen Zielknoten gebunden?
• Wie werden abgelaufene oder manipulierte Token behandelt?
• Welche Auswirkungen hat eine vorübergehende Nichterreichbarkeit von Keycloak?
• Wie werden Signaturschlüssel erneuert?
• Wie werden Aktionen über mehrere Knoten hinweg protokolliert?

Insbesondere soll zwischen Delegation und Impersonation unterschieden werden. Ein Odysseus-Knoten darf nicht ohne nachprüfbaren Auftrag beliebig die Identität eines Benutzers annehmen.

Beispielhafter Ablauf

Ein möglicher Ablauf bei der verteilten Ausführung einer Anfrage ist:

1. Der Benutzer meldet sich über OpenID Connect am WebStudio an.
2. Keycloak stellt ein Access Token für den Zugriff auf Knoten A aus.
3. Das WebStudio sendet die Anfrage und das Access Token an Knoten A.
4. Knoten A validiert das Token und prüft die Berechtigung zum Erstellen der Anfrage.
5. Knoten A stellt fest, dass ein Teil der Anfrage auf Knoten B ausgeführt werden soll.
6. Knoten A fordert bei Keycloak ein kurzlebiges Token für Knoten B an.
7. Keycloak prüft, ob Knoten A zu diesem Token Exchange berechtigt ist.
8. Knoten A überträgt die Teilanfrage mit dem neuen Token an Knoten B.
9. Knoten B validiert Signatur, Audience, Laufzeit und Scopes.
10. Knoten B legt die Teilanfrage unter der Identität des ursprünglichen Benutzers an.
11. Benutzer, aufrufender Knoten und ausgeführte Aktion werden protokolliert.

Fragestellungen

Die Arbeit soll unter anderem folgende Fragen untersuchen:

• Wie kann Keycloak in die bestehende Odysseus-Architektur integriert werden?
• Wie werden WebStudio und Odysseus-Knoten als Clients modelliert?
• Welche Vor- und Nachteile besitzen direkte Tokenweitergabe und Token Exchange?
• Wie können Benutzer- und Dienstidentität gemeinsam dargestellt werden?
• Welche Rollen und Scopes werden für verteilte Anfragen benötigt?
• Wie lässt sich sicherstellen, dass ein delegiertes Token nicht mehr Rechte besitzt als der ursprüngliche Benutzer?
• Wie kann ein Token an einen bestimmten Zielknoten gebunden werden?
• Wie können Token lokal validiert werden, ohne Benutzerpasswörter zu übertragen?
• Wie werden Ressourcenbesitz und globale Rollen miteinander kombiniert?
• Wie können bestehende Installationen schrittweise auf Keycloak umgestellt werden?
• Welchen Einfluss haben Tokenvalidierung und Token Exchange auf Latenz und Verfügbarkeit?

Evaluation

Der entwickelte Ansatz soll in einer Testumgebung mit Keycloak, WebStudio und mindestens zwei Odysseus-Knoten evaluiert werden.

Dabei sollen unter anderem folgende Szenarien untersucht werden:

• erfolgreiche Anmeldung über Keycloak,
• erlaubter Zugriff mit ausreichenden Berechtigungen,
• Zugriff ohne die benötigte Berechtigung,
• direkte Weitergabe eines Benutzer-Tokens,
• Austausch eines Tokens für einen Zielknoten,
• Verwendung eines abgelaufenen Tokens,
• Verwendung eines Tokens mit falscher Audience,
• manipuliertes oder ungültig signiertes Token,
• Versuch einer Rechteausweitung,
• technische Operation mit einem Service Account,
• verteilte Anfrage unter Beibehaltung der Benutzeridentität,
• vorübergehende Nichterreichbarkeit von Keycloak,
• Aktualisierung der von Keycloak verwendeten Signaturschlüssel.

Mögliche Bewertungskriterien sind:

• korrekte Durchsetzung der Berechtigungen,
• Verhinderung unzulässiger Zugriffe,
• zusätzliche Latenz durch Tokenvalidierung und Token Exchange,
• Verhalten bei nicht erreichbarem Keycloak,
• Nachvollziehbarkeit verteilter Aktionen,
• benötigte Änderungen an bestehenden Odysseus-Komponenten,
• Reduzierung administrativer Knotenverbindungen,
• Übertragbarkeit auf andere OpenID-Connect-Provider.

Abgrenzung

Im Mittelpunkt stehen die Authentifizierung über Keycloak und die Delegation von Identität und Berechtigungen zwischen Odysseus-Knoten.

Nicht zwingend Bestandteil der Arbeit sind:

• die sofortige vollständige Ablösung des bestehenden Benutzermanagements,
• die Anpassung sämtlicher REST-Endpunkte,
• die Entwicklung eines eigenen Identity Providers,
• die Implementierung eigener kryptografischer Verfahren,
• eine organisationsübergreifende Identity-Föderation,
• komplexe attributbasierte Autorisierungsrichtlinien,
• ein vollständiges Administrationsfrontend,
• Single Sign-on für sämtliche Werkzeuge des Odysseus-Ökosystems,
• eine produktionsreife Hochverfügbarkeitskonfiguration von Keycloak.

Die prototypische Umsetzung kann auf ausgewählte Operationen aus dem Lebenszyklus verteilter Anfragen begrenzt werden.

Erwartete Ergebnisse

Am Ende der Arbeit sollen vorliegen:

• eine Analyse des bestehenden Benutzermanagements und der Knotenkommunikation,
• ein dokumentiertes Sicherheits- und Vertrauensmodell,
• eine reproduzierbare Keycloak-Testkonfiguration,
• ein Client-, Rollen- und Scope-Modell,
• eine OpenID-Connect-Anbindung des WebStudios,
• eine lokale JWT-Validierung auf Odysseus-Knoten,
• die Abbildung von Tokeninformationen auf den Odysseus-Sicherheitskontext,
• die delegierte Ausführung ausgewählter Operationen,
• eine prototypische Integration des Keycloak Token Exchange,
• Audit-Informationen mit Benutzer- und Knotenidentität,
• automatisierte Funktions- und Sicherheitstests,
• eine Evaluation in einer verteilten Testumgebung,
• ein Konzept zur schrittweisen Migration des bestehenden Benutzermanagements.

Voraussetzungen

Hilfreich sind Kenntnisse oder Interesse in folgenden Bereichen:

• Programmierung mit Java,
• verteilte Systeme,
• REST-basierte Kommunikation,
• Authentifizierung und Autorisierung,
• Grundlagen von OAuth 2.0, OpenID Connect und JWT,
• IT-Sicherheit und Bedrohungsmodelle,
• Softwaretests und experimentelle Evaluation.

Kenntnisse über Odysseus, Keycloak, OAuth oder OpenID Connect werden nicht vorausgesetzt und können im Rahmen der Arbeit erworben werden.