Softwarearchitektur verstehen und entscheiden

Aaron KreisÜber mich
Sicherheitsarchitektur

Single Sign On

Einmal anmelden, viele Anwendungen nutzen

Die Idee und ihr Nutzen

Frau Berg arbeitet in der Schadenabteilung einer Versicherung und nutzt im Laufe des Tages das Schadenportal, das Vertragsportal und weitere Programme. Morgens meldet sie sich einmal bei einem gemeinsamen Identitätsdienst an, einem eigenen Programm, das Benutzernamen und Passwörter prüft. Danach kann sie das Schadenportal und das Vertragsportal öffnen, ohne ihr Passwort erneut einzugeben. Jedes Portal prüft den Anmeldenachweis, eine Bestätigung der Anmeldung, die der Identitätsdienst ausstellt. Welche Fälle Frau Berg sehen und welche Handlungen sie ausführen darf, entscheidet jedes Portal weiterhin selbst. Dieses Verfahren heißt Single Sign On, abgekürzt SSO, auf Deutsch Einmalanmeldung.

Bausteine: Identitätsdienst: prüft das Passwort, merkt sich die Anmeldung; Frau Berg: Sachbearbeiterin; Schadenportal: prüft den Nachweis, entscheidet über Rechte selbst; Vertragsportal: prüft den Nachweis, entscheidet über Rechte selbst. Verbindungen: Frau Berg — Identitätsdienst (Passwort, einmal); Frau Berg — Identitätsdienst (Anmeldenachweis); Frau Berg — Schadenportal (mit Anmeldenachweis); Frau Berg — Vertragsportal. Frau Berg meldet sich einmal beim Identitätsdienst an; Schadenportal und Vertragsportal erkennen dessen Anmeldenachweis an und entscheiden selbst, was Frau Berg darf.

Wie funktioniert es?

Frau Berg öffnet morgens das Schadenportal und ist noch nicht angemeldet. Das Schadenportal leitet sie zur Anmeldung an den Identitätsdienst weiter. Beim Identitätsdienst gibt Frau Berg einmal Benutzername, Passwort und einen zusätzlichen Code ein. Den Code liefert zum Beispiel eine App auf ihrem Telefon. Der Identitätsdienst speichert die Anmeldung und schickt Frau Berg mit einem Anmeldenachweis zum Schadenportal zurück. Das Schadenportal fragt beim Identitätsdienst, ob der Nachweis echt ist, und erhält die Antwort „echt: Frau Berg“. Danach richtet das Schadenportal eine eigene Sitzung für Frau Berg ein, also einen Zeitraum, in dem das Schadenportal Frau Berg wiedererkennt, ohne erneut beim Identitätsdienst nachzufragen. Das Schadenportal zeigt ihr nur die Fälle, die ihr zugewiesen sind, nicht alle Fälle der Abteilung. Am Nachmittag öffnet Frau Berg das Vertragsportal. Das Vertragsportal fragt beim Identitätsdienst, ob Frau Berg angemeldet ist, und der Identitätsdienst antwortet „ja, neuer Nachweis“. Frau Berg muss kein Passwort eingeben. Welche Verträge sie ändern darf, prüft das Vertragsportal selbst.

Die Portale geben die Prüfung von Benutzername und Passwort an den Identitätsdienst ab. Der Identitätsdienst führt die Konten aller Mitarbeitenden, prüft bei der Anmeldung das Passwort und je nach Einstellung den zusätzlichen Code und speichert, wer angemeldet ist. Für jedes Portal stellt der Identitätsdienst einen eigenen Anmeldenachweis aus. Jedes Portal prüft, ob der Anmeldenachweis echt ist und vom Identitätsdienst stammt. Das Schadenportal fragt zur Prüfung beim Identitätsdienst nach; andere Verfahren prüfen stattdessen eine digitale Unterschrift im Nachweis, ohne nachzufragen. Nach der Prüfung richtet jedes Portal eine eigene Sitzung ein. Der Identitätsdienst beantwortet nur die Frage „Wer ist diese Person?“; welche Rechte die Person hat, legt jedes Portal in seiner eigenen Rechteverwaltung fest. Frau Bergs Kollege Herr Kurz meldet sich beim selben Identitätsdienst an, hat im Schadenportal aber andere Rechte: Herr Kurz darf Schäden bearbeiten, aber keine Auszahlungen freigeben. In welcher Reihenfolge jemand die Portale öffnet, spielt für das Verfahren keine Rolle.

Ist die Anmeldung beim Identitätsdienst inzwischen abgelaufen, fragt der Identitätsdienst beim Öffnen des Vertragsportals wieder nach Passwort und Code. Scheitert die Prüfung eines Nachweises, etwa weil er abgelaufen oder verfälscht ist, richtet das Portal keine Sitzung ein und schickt Frau Berg erneut zur Anmeldung. Meldet sich Frau Berg im Schadenportal ab, läuft ihre Sitzung im Vertragsportal weiter, bis sie abläuft; eine gemeinsame Abmeldung in allen Portalen muss eigens eingerichtet werden.

Single Sign-on: einmal anmelden, beide Portale nutzen

Beteiligte: Frau Berg: Sachbearbeiterin; Schadenportal: zeigt ihr ihre Fälle, prüft Rechte selbst; Identitätsdienst: prüft das Passwort einmal; Vertragsportal: prüft Rechte selbst. Ablauf: 1. Frau Berg öffnet morgens das Schadenportal und ist noch nicht angemeldet. 2. Das Schadenportal leitet Frau Berg zur Anmeldung an den Identitätsdienst weiter. 3. Frau Berg gibt beim Identitätsdienst einmal Benutzername, Passwort und Code ein. Der Identitätsdienst speichert die Anmeldung. 4. Der Identitätsdienst schickt Frau Berg mit einem Anmeldenachweis zum Schadenportal zurück. 5. Das Schadenportal erhält den Anmeldenachweis. 6. Das Schadenportal fragt beim Identitätsdienst, ob der Nachweis echt ist. Andere Verfahren prüfen stattdessen eine digitale Unterschrift. 7. Der Identitätsdienst bestätigt „echt: Frau Berg“. Das Schadenportal richtet eine eigene Sitzung ein. 8. Das Schadenportal zeigt Frau Berg nur ihre zugewiesenen Fälle, nicht alle der Abteilung. 9. Frau Berg öffnet das Vertragsportal. 10. Das Vertragsportal fragt beim Identitätsdienst, ob Frau Berg angemeldet ist. 11. Der Identitätsdienst antwortet „ja, neuer Nachweis“, und Frau Berg muss kein Passwort eingeben. Welche Verträge sie ändern darf, prüft das Vertragsportal selbst.

Wann ist es sinnvoll und wann nicht?

Single Sign On lohnt sich

  • Dieselben Menschen nutzen mehrere Anwendungen. Das sind etwa die Mitarbeitenden eines Unternehmens oder die Kunden einer Firma mit mehreren Portalen. Ohne gemeinsame Anmeldung meldet sich Frau Berg morgens am Schadenportal, nachmittags am Vertragsportal und zwischendurch am Buchhaltungsprogramm an, jedes Mal mit einem eigenen Benutzernamen und Passwort. Sie muss sich viele Passwörter merken, und viele Menschen verwenden deshalb überall dasselbe oder schreiben es auf.
  • Konten sollen nur einmal beim Identitätsdienst angelegt und gesperrt werden. Ohne gemeinsame Anmeldung muss für eine neue Mitarbeiterin in jedem Portal ein eigenes Konto angelegt werden. Verlässt jemand das Unternehmen, muss sein Zugang in jedem Portal einzeln gesperrt werden. Wird dabei ein Portal vergessen, bleibt in diesem Portal ein Zugang offen.
  • Ein zusätzlicher Code auf dem Telefon soll für alle Anwendungen einheitlich verlangt werden. Ohne Identitätsdienst müsste das Team jedes Portals die Abfrage des Codes selbst einbauen, und ein Portal ohne diese Abfrage bliebe allein mit dem Passwort erreichbar. Der Identitätsdienst fragt den Code ab und schützt damit alle angeschlossenen Portale, ohne dass die Abfrage in jede Anwendung einzeln eingebaut werden muss.

Single Sign On ist nicht das Richtige

  • Es gibt nur eine einzige Anwendung, etwa wenn die Schadenabteilung nur das Schadenportal nutzt. Es gibt dann keine zweite Anmeldung, die Single Sign On ersparen könnte. Dann prüft die Anwendung Benutzername und Passwort selbst. Ein eigener Identitätsdienst, der zusätzlich betrieben und abgesichert werden muss, entfällt.
  • Eine Anwendung muss auch erreichbar sein, wenn der Identitätsdienst ausfällt, und für diesen Fall gibt es keinen Notzugang. Mit Single Sign On könnte sich bei einem Ausfall des Identitätsdienstes niemand bei dieser Anwendung neu anmelden. Dann behält diese Anwendung eine eigene Anmeldung mit eigenen Konten, die das Team der Anwendung selbst anlegt und sperrt. Fällt der Identitätsdienst aus, können sich die Mitarbeitenden bei dieser Anwendung weiter anmelden.
  • Die Anwendungen werden von völlig verschiedenen Personengruppen genutzt, die keine Anwendung gemeinsam haben. Ein Beispiel sind ein Portal nur für Kunden und ein Programm nur für die Buchhaltung. Dann behält jede Anwendung ihre eigene Anmeldung. Ein gemeinsamer Identitätsdienst würde niemandem eine zweite Passworteingabe ersparen, weil sich ohnehin niemand bei mehr als einer Anwendung anmeldet.
  • Eine ältere Anwendung wie das Buchhaltungsprogramm unterstützt kein Anmeldeverfahren mit einem Identitätsdienst. Single Sign On lässt sich für diese Anwendung dann nicht einrichten. Das Buchhaltungsprogramm behält seine eigene Anmeldung und übernimmt die Konten aus einem gemeinsamen Verzeichnis der Mitarbeitenden, das auch der Identitätsdienst nutzt. Ein Konto muss dann nur einmal angelegt und gesperrt werden. Frau Berg hat zwar überall dasselbe Passwort, muss es aber im Buchhaltungsprogramm erneut eingeben, und das Buchhaltungsprogramm sieht ihr Passwort.

Nachteile und typische Fehler

Alle Anmeldungen hängen vom Identitätsdienst ab, und er braucht deshalb einen eigenen Ausfallschutz. Das Team des Identitätsdienstes und die Teams der Portale müssen gemeinsam festlegen, wie lange eine Sitzung in jedem Portal läuft und ob eine Abmeldung oder eine Sperrung beim Identitätsdienst auch die Sitzungen in den Portalen beendet. Jede Anwendung muss an den Identitätsdienst angebunden und beim Identitätsdienst eingetragen werden. Die Anwendungen hängen außerdem vom Verfahren und von den Einstellungen des Identitätsdienstes ab: Ändert sich etwa die Art, wie Nachweise unterschrieben werden, müssen alle Portale die Änderung mitmachen.

Typische Fehler und woran man sie erkennt:

  • Übernommenes Konto: Beim Identitätsdienst ist kein zusätzlicher Code eingestellt. Ein Angreifer erbeutet Benutzername und Passwort von Frau Berg und meldet sich damit beim Identitätsdienst an. Danach öffnet der Angreifer Schadenportal und Vertragsportal, und der Identitätsdienst stellt für beide Portale einen Nachweis für Frau Berg aus. Mit einer einzigen Anmeldung erreicht der Angreifer so alle angeschlossenen Anwendungen. Erkennbar ist eine solche Übernahme an Anmeldungen desselben Kontos von ungewöhnlichen Orten oder zu ungewöhnlichen Zeiten in mehreren Portalen kurz hintereinander.
  • Ausfall des Identitätsdienstes: Fällt der Identitätsdienst aus, kann kein Portal einen neuen Nachweis erhalten, und niemand kann sich neu anmelden, obwohl alle Portale laufen. Nur wer schon eine Sitzung in einem Portal hat, arbeitet dort weiter, bis diese Sitzung abläuft. Erkennbar ist das an Anmeldefehlern in allen Portalen zur selben Zeit.
  • Gesperrt, aber noch angemeldet: Ein Mitarbeiter verlässt das Unternehmen, und sein Konto wird beim Identitätsdienst gesperrt. Seine Sitzung im Schadenportal läuft aber weiter, denn während einer Sitzung fragt das Schadenportal nicht beim Identitätsdienst nach. Der ausgeschiedene Mitarbeiter kann weiterarbeiten, bis diese Sitzung abläuft. Erkennbar ist das an Zugriffen in einem Portal nach dem Zeitpunkt der Sperrung.
  • Anmeldung mit Berechtigung verwechselt: Ein Portal schließt aus der erfolgreichen Anmeldung, die Person dürfe alles, und prüft ihre Rechte nicht. Herr Kurz könnte dann im Schadenportal Auszahlungen freigeben, und Frau Berg sähe alle Fälle der Abteilung. Erkennbar ist das an Handlungen, die zur Rolle der Person nicht passen.
  • Ungeprüfter Nachweis: Ein Portal übernimmt den Anmeldenachweis, ohne zu prüfen, ob er vom Identitätsdienst stammt. Ein Angreifer legt dem Portal einen selbst erstellten Nachweis mit dem Namen von Frau Berg vor, und das Portal richtet eine Sitzung für Frau Berg ein. Erkennbar ist das an Sitzungen im Portal, zu denen der Identitätsdienst keine Anmeldung verzeichnet hat.

Weiterführend

Verwandte Ansätze

  • Token Based Authentication: beschreibt Anmeldenachweise, die eine Anwendung selbst prüfen kann, etwa anhand einer digitalen Unterschrift. Solche Nachweise sind ein verbreitetes Mittel, um Single Sign On umzusetzen.
  • Role Based Access Control: legt fest, was eine angemeldete Person in einer Anwendung darf, etwa dass Herr Kurz Schäden bearbeiten, aber keine Auszahlungen freigeben darf.
  • Zero Trust: prüft jeden Zugriff einzeln anhand von Identität und Regeln. Ein gemeinsamer Identitätsdienst liefert dafür die Angabe, wer zugreift.
  • Least Privilege: Jede Person erhält in jeder Anwendung nur die Rechte, die sie für ihre Arbeit braucht. Die gemeinsame Anmeldung ändert an diesem Grundsatz nichts.

Quellen

  • OpenID Foundation: OpenID Connect Core 1.0: Standard für die Anmeldung über einen Identitätsdienst; beschreibt die Weiterleitung zum Identitätsdienst, die Rückkehr mit einem Anmeldenachweis, dessen digitale Unterschrift die Anwendung prüfen muss, und die Abfrage einer bestehenden Anmeldung ohne erneute Passworteingabe.
  • Microsoft: What is single sign-on in Microsoft Entra ID?: beschreibt an einem verbreiteten Identitätsdienst, wie eine einmalige Anmeldung den Zugang zu vielen Anwendungen öffnet und die Verwaltung der Konten zentral bündelt.