---
title: "Identität in verteilten Systemen – Ein Erfahrungsbericht"
url: "https://www.intersim.ch/insights/identitat-in-verteilten-systemen-ein-erfahrungsbericht"
description: "Im Verlauf des letzten Jahres durften wir für den Schulverlag ein neues Login- und Lizenzsystem umsetzen. Nachfolgend möchte ich beschreiben, welche Hürden…"
---

# Identität in verteilten Systemen – Ein Erfahrungsbericht

[Technik & Innovation](/insights/?filter=technology-innovation)

 ![Identitätskarte in Laptop](/_astro/identitat-online.BniIfqEd_TpWW3.jpg)

Im Verlauf des letzten Jahres durften wir für den [Schulverlag](https://www.schulverlag.ch/) ein neues Login- und Lizenzsystem umsetzen. Nachfolgend möchte ich beschreiben, welche Hürden wir dabei nehmen mussten, welche Kompromisse wir eingehen mussten und was wir aus diesem Projekt für die Zukunft mitnehmen.

Autor:in

Mark Mancktelow

Veröffentlicht

27\. Juli 2020

## Hürwsl den

Die erste Hürde, die wir nehmen mussten, war, **das Konzept von geschützten Ressourcen zu etablieren**. Herkömmliche Systeme sind in der Regel so gebaut, dass auf öffentlichen Seiten ein Link zur Login Maske platziert wird. Nach dem Login über diese lokale Maske befindet sich der Benutzer wieder auf der öffentlichen Seite, ist aber eingeloggt. Danach sind – meist im Menü – Verweise auf geschützte Bereiche sichtbar.

Wenn nun aber ein zentrales Login für diverse verteilte Systeme (Webseiten, Apps, APIs etc., nachfolgend zur besseren Leserlichkeit einfach „Webseite“) angeboten wird, **soll der Benutzer aber nach einer einmaligen Anmeldung bei allen Webseiten angemeldet sein**. Dies hat jedoch einen Haken: Die aufgerufene Webseite weiss zu Beginn nicht, ob der Benutzer sich bei der zentralen Identitätsverwaltung (nachfolgen IDP für „Identity Provider“) schon angemeldet hat. Da der IDP eine eigenständige Webseite ist, gibt es auch keine Möglichkeit, dies in dieser zu ermitteln. Es muss auf den IDP umgeleitet werden.

Dieser prüft dann, ob der Benutzer eingeloggt ist. Wenn nicht, wird eine Login Maske angezeigt und nach erfolgtem Login zurück auf die aufzurufende Webseite geleitet. Die von der Webseite benötigten **Informationen zum Benutzer werden dabei mitgeliefert**. Ist der Benutzer bereits angemeldet, so entfällt das Einloggen und der Benutzer wird ohne Interaktion direkt wieder zurückgeleitet, wobei auch hier die benötigten Informationen dabei sind. Die Crux dabei ist, dass in beiden Fällen ein eingeloggter Benutzer zurückkommt.

Nun kann weiterhin genauso vorgegangen werden, wie dies im ersten Abschnitt beschrieben wurde: Seite aufrufen und ‚Login‘ klicken. Ist der Benutzer beim IDP schon eingeloggt, ist keine weitere Interaktion nötig. **Der Benutzer wird allein durch den Klick auf ‚Login‘ angemeldet**.

Dies bietet jedoch nicht das optimale Erlebnis für den Benutzer. **Ideal wäre** eine Verwendung, bei der **fliessend in den angemeldeten Zustand gewechselt wird**. Dies kann erreicht werden, indem geschützte Ressourcen von öffentlichen getrennt werden. Der Aufruf der Startseite könnte beispielsweise öffentlich sein; der Shop wäre jedoch geschützt. Wenn dann der Benutzer auf Shop klickt, wird, falls er lokal auf der Webseite noch nicht angemeldet ist, beim IDP der oben beschriebene Vorgang angestossen. Der Ablauf ist also entweder  
**Startseite -> anmelden beim IDP -> Shop**  
**oder Startseite -> Shop.**

Im zweiten Fall wird zwar genau gleich auf den IDP umgeleitet, doch dieser leitet direkt auf den Shop weiter. Der Benutzer bekommt davon nichts mit.

Nun habe ich also dargelegt, wie beim Aufruf einer geschützten Ressource die Anmeldung (still, falls schon zentral angemeldet) dazwischengeschaltet wird.

Der entscheidende Punkt, der das grösste Umdenken gegenüber herkömmlichen Systemen darstellt und darum die erste Hürde war, ist, dass dies **der einzige Weg ist das Login aufzurufen**. Es wird auf Seite der Webseiten nie ein Link auf die zentrale Login Maske hinterlegt. Denn wird direkt auf die Maske verlinkt, fehlt der Kontext, um nach erfolgter Anmeldung wieder zurück auf die Webseite zu leiten.

Die **zweite Hürde** ist schneller dargelegt: Als spezifische Umsetzung für den IDP haben wir für Schulverlag **OpenId Connect openid.net (Oidc) gewählt**. Dies ist der aktuell beste Stand der Technik und wird z.B. auch von Google und Microsoft für solche Szenarien verwendet. Will man sich – wie ich – bis in die Details damit beschäftigen, schwappt **eine Welle von Spezifikationen und kryptographischen Überlegungen entgegen**. Diese sind nicht für gleich verständlich und können daher abschrecken.

Obwohl wir die Mehrheit der Anbieter von Webseiten, die an unseren IDP angebunden wurden, mit mehr oder weniger Aufwand überzeugen konnten, auf **diese moderne und zukunftsträchtige Lösung zu setzen**, sind noch nicht alle an Bord. Dabei ist die Anbindung an das System durch den Einsatz bewährter Software-Bibliotheken ein Leichtes und in erstaunlich kurzer Zeit umsetzbar. Man muss für den korrekten Einsatz der Technologie nicht alle Details davon verstehen. Es ist jedoch sehr empfehlenswert, für ein solches Projekt **mindestens einen Experten mit einzubeziehen**, an den sich die anderen Beteiligten bei Fragen wenden können.

Obwohl ich mich inzwischen selbst als Experten auf diesem Gebiet bezeichne, habe ich die Grundarchitektur des Systems für den Schulverlag mit Damien Bowden (damienbod.com) durchdiskutiert und von ihm auf konzeptionelle Mängel prüfen lassen.

![Screenshot Login Schulverlag](/_astro/schulverlag-login.DAA7UC0Z_1KnwyS.webp)

## Kompromisse

Bei den Hürden habe ich dargelegt, wie eine einzelne Webseite mit dem IDP zusammenarbeitet. Doch **was ist, wenn auf dieser Webseite ein Link auf eine andere vorkommt, die ebenfalls mit unserem IDP verhängt ist?**

Durch die Verwendung von Oidc und den damit verbundenen Tokens, in welchen die benötigten Informationen über den Benutzer zwischen IDP und Webseite ausgetauscht werden, ist es technisch möglich, dass die erste Seite beim Aufruf der 2. Seite diese Informationen mit schickt. Damit würde die zweite Seite anders als die Erste im Aufruf bereits alle Informationen über den Benutzer erhalten und könnte schon beim ersten Aufruf im eingeloggten Zustand erscheinen.

**Leider konnte diese ideale Welt aber nicht umgesetzt werden, da die meisten der angebundenen Seiten bereits im Einsatz waren**. Ein Umbau aller beteiligten Systeme, sodass bei Aufruf der anderen immer die Login-Informationen mitgeliefert würden, wäre nicht wirtschaftlich gewesen. Darum fungiert unter dem Schirm des zentralen IDP jede Seite des Schulverlags autonom: Nach der Traverse von einer Seite zur anderen (z.B. Lizenzverwaltung zum Shop), muss diese sich selbst wieder beim IDP melden.

Ein weiterer Kompromiss ergab sich direkt aus dem ersten: Hätten wir bei der Traverse darauf gebaut, immer die Benutzerinformationen mit zu liefern, so wäre es auch sinnvoll gewesen, die Lizenzinformationen mit rein zu packen. So hätte jede Webseite nicht nur gewusst, wer daherkommt, sondern auch was lizenziert ist. Bei vielen Lizenzen wäre das Token aber sehr gross geworden. Und dieses Token wird sehr viel hin und her gesandt.

Darum haben wir entschieden, das **Token möglichst klein zu gestalten**, während das Lizenzsystem eine Schnittstelle anbietet, über die alle aktiven Lizenzen für das mitgelieferte Token bezogen werden können. So bleiben insbesondere Webseiten, die nur Anmeldeinformationen aber keine Lizenzen verwenden, von diesen verschont.

Auch haben wir noch gewisse Teile und Schnittstellen im System, die nicht über Oidc gesichert sind. Diese Brüche sind dadurch entstanden, dass nicht alle Systeme auf diese neue Technik setzen konnten oder wollten.

## Lehren

Trotz des **Erfolgs** der Umsetzung für den Schulverlag **nehmen auch wir einige Punkte mit**, bei denen wir bei einem zukünftigen, ähnlichen Projekt anders verfahren würden.

Der erste und wichtigste Punkt ist eine engere Begleitung der anderen Firmen, die mit ihren Lösungen an unseren IDP angebunden wurden. Ich habe vorausgesetzt, dass diese schon fragen würden, wenn sie Oidc nicht kennen oder bei dessen Umsetzung Fragen haben. Leider haben sie zum Teil lange mit Problemen gekämpft, die durch engere Begleitung und Unterstützung schnell hätten behoben werden können.

An zweiter Stelle möchte ich auf die bei den Kompromissen erwähnte, **nur unvollständige Anwendung von Oidc zurückkommen**: Wenn ein System nicht daran angebunden wird, fragen sich andere, warum sie sich mit dieser neuen Sache beschäftigen sollen. Sie könnten sich auch eine Ausnahme ausbedingen. So beginnt eine schleichende Rückkehr zur „alten“ Welt, in der jede Interaktion zwischen verschiedenen Webseiten die Probleme der Identität individuell gelöst haben. Wenn eine Seite eine Schnittstelle aufruft, die wiederum eine andere Schnittstelle (oder gar Schnittstellen) benötigt, so ist eine Standardisierung der einzige Weg, auch zukünftige Anpassungen effizient umsetzen zu können und dabei die Sicherheit des Systems als Ganzes zu garantieren.

Rückblickend wäre es **einfacher und effizienter** gewesen, diese **Kompromisse nicht einzugehen**.

## Fazit

Der Einsatz einer **modernen, auf Oidc basierenden, zentralen Identitätsverwaltung lohnt sich** insbesondere dann, wenn verschiedene Systeme (auch von verschiedenen Anbietern) mit einer einzigen Identität verwendet werden sollen. Das Erlebnis für die Benutzer ist besser und der Supportaufwand geringer.

Auch konnten wir föderierte Logins anbieten, bei der sich eine Untergruppe der Benutzer über ein eigenes AD-Login anmelden konnte. Hier eröffnen sich haufenweise Möglichkeiten.

Das System hat sich voll und ganz bewährt. Wir werden auch in Zukunft für ähnliche Szenarien auf Oidc setzen und diesen Weg mit Freude und Überzeugung gehen.

![Screenshot Mathebuch Schulverlag](/_astro/mathbuch_schulverlag.DLdSF7AT_Z22EqM3.webp)

## Verwandte Themen

Weiterführende Projekte und Inhalte zum Thema

[Website](/projects/?filter=web) [Mobile-App](/projects/?filter=app)