Authentifizierung im Wandel der Zeit

Wer auf Daten und Informationen zugreifen will, muss sich sich legitimieren. Dazu gehört die Authentifizierung, d.h. der Beweis dass ich der bin, für den ich mich ausgeben und im zweiten Schritt die Autorisierung, mit der die Datenquelle steuert, was ich darf. Diese Grundprinzipien sind seit vielen Jahrzehnten umgesetzt aber unterliegen der ein oder anderen Veränderung. Diese Seite beschreib die Evolution und den aktuellen Stand z.B. beim Einsatz von Webseiten und Microsoft Graph. Das war auch der Anlass diese Seite zu schreiben.

Client und ein Dienst

In den Anfängen der Datenverarbeitung haben wir noch nicht über Netzwerke, verteilte Systeme oder gar das Internet mit Apps nachgedacht. Da gab es in der Regel ein Terminal, welches an einen Host angebunden war. Wir haben uns mit einem Benutzernamen und Kennwort angemeldet und konnten dann im Rahmen unserer Möglichkeiten Dateien bearbeiten und Programme starten.

Protokolle wie TELNET oder SERIAL mit Emulationen wie VT220, VT100, ANSI etc. waren hoch im Kurs. Zu der Zeit war man froh einen "Host" nutzen zu können. Beim Zugriff auf Server waren aber schon mehrere Anmeldeverfahren möglich. Die ersten Formen eines Handshake entstanden, bei denen der Client erst einmal "anonym" zugegriffen hat und im Fehler auch die Optionen codiert waren.

Die Details dazu finden sie auf HTTP Authentication. Diese Anmeldung wird heute auch als "Legacy Anmeldung" bezeichnet. Sie hat mehrere Schwächen, z.B.:

  • Jeder Service muss selbst die Gültigkeit prüfen
  • Jeder Service muss selbst die Verschlüsselung und Sicherung der Zugangsdaten gewährleisten
  • Conditional Access und MFA muss jeder Service selbst umsetzen
  • Jeder Service muss selbst sich gegen Anmeldeattacken wehren

All das wird nicht benötigt, wenn Sie sich in einem privaten geschlossenen Netzwerk (LAN) befinden und Bandbreite und Laufzeiten vernachlässigt werden können. Server, die aber im Internet stehen, können so sehr viel einfacher "gestört" werden. Im Internet kommen immer mehr "Token-basierte" Verfahren zum Einsatz.

Client und mehrere Dienste

Sehr schnell wurden es aber mehr Dienste, die auf unterschiedlichen Servern bereitgestellt wurden. Bei der Nutzung der klassischen alten Terminals war man mit einem Server verbunden und hat sich von dort dann auf den nächsten Server "durchgeschaltet". Auf jedem Server hatte man aber einen eigenen Benutzer und Kennwort mit eigenen Berechtigungen. Das gibt es auch noch heute, wenn Sie z.B. mehrere Postfächer bei verschiedenen Diensten nutzen. Die meisten Leser werden vermutlich ein Konto bei Apple (Appstore) oder Google (Playstore) haben und irgendwo anders noch ein POP3/IMAP4-Kennwort für die Mailbox bei GMX, Web.de oder ihrem eigenen Hosting.

Allerdings ist es auf Dauer natürlich nicht effektiv mit verschiedenen Konten zu arbeiten.

Client mit Domänen (NTFS)

Speziell in Firmen und mit der Verbreitung von vollwertigen Computern als Clients ganz sehr sehr früh den Bedarf mehrere Systeme zusammen zuschalten und die gleichen Authentifizierungsdienste zu nutzen. Das Zeitalter der Domänen war geboren. Dabei war die Windows-Domäne gar nicht mal zuerst da. Es gab davor schon NDS (Novell NetWare), Streettalk (Banyan Vines), NIS/YP (SUN/UNIX) und viele andere. Alle Server in dem Verbund aber auch die Client "vertrauen" dem Verzeichnisdienst und nutzen dessen Datenbank über Personen, Gruppen und die Authentifizierung.

Bis NT4 kennen die meisten Administratoren heute noch die klassische "Domäne", in der Server und Client Mitglied waren. Der große Vorteil war, dass der Anwender und seine Gruppenmitgliedschaften nur noch an einer Stelle zu pflegen waren. Für den Anwender gab es aber noch den Vorteil, dass er sich idealerweise nur einmal an seinem Client anmelden musste, und der sich dann zu den verschiedenen Servern verbunden hat. Die Zeit von "NTLM" als Anmeldeverfahren war geboren. Allerdings mussten die Server den NTLM-Hash immer noch gegen den Domaincontroller verifizieren. Erst dann konnte der Service sicher sein, dass der Benutzer authentisch ist und aus dem Anmeldepaket auch die Gruppenmitgliedschaften extrahieren. Mit der Liste der SIDs konnte der Service dann bestimmen, welche Daten der Anwender zu Gesicht bekommt.

Client und Kerberos

Die Nutzung von NTLM hat sehr schell die Grenzen der Skalierung aufgezeigt, das jeder Dienst immer wieder einen der Domain Controller befragen musste. In größeren und womöglich geografisch verteilten Umgebungen mit langen Paketlaufzeiten hat es nicht nur sehr lange gedauert, bis eine Anmeldung erfolgt war. Server konnten meist nur zwei parallel Authentifizierungen durchführen, so dass auch hier Engpässe offensichtlich wurden. Störend war aber auch, dass jeder Zugriff selbst zum gleichen Server und einer anderen Dateifreigabe neu authentifiziert werden musste. Mit Windows 2000 hat Microsoft dann Kerberos als weiteres Authentifizierungsverfahren integriert. Der Client kommuniziert damit mit dem KDC (Kerberos Distribution Center) und bekommt einen kryptografisch gesichertes Token, welches alle Daten enthält.

Mit diesem Token kann der Client dann immer wieder auf den Service zugreifen, solange das Token gültig ist (meist 8h).

Der Service selbst bekommt das Token und kann es decodieren, weil es mit dem öffentlichen Schlüssel des Zielsystem verschlüsselt und dem privaten Key des KDC signiert ist. Der Server bekommt also den Zugriff mit dem Token und kann sofort erkennen, wer der Konto hier ankommt und in welchen Gruppen es Mitglied ist. Der Service muss nicht mehr mit dem Domain Controller im Hintergrund sprechen.

Einzige Einschränkung dabei ist, dass die meisten Domain Controller natürlich nicht im "Internet" stehen und daher diese Funktion nur im firmeninternen Netzwerk oder VPN funktioniert. Da es aber immer noch Dienste gibt, die kein Kerberos unterstützen, sind natürlich auch weiterhin die älteren Anmeldeverfahren möglich, z.B. NTLMv2.

Client und OAUTH Tickets

Kerberos ist schon sehr nahe an der idealen Welt, da der Service einfach den Benutzer und seine Gruppen versteht. Aber funktioniert so natürlich nicht im Internet. OAUTH und Tickets sind quasi die Weiterentwicklung von Kerberos für das Internet. Auch hier verbindet sich der Client zu einem Service, der ihn dann aber z.B. per HTTP-Redirect zu einem Federation-Server schickt. Vergleichen Sie das einfach mit einem Fahrkartenschalter im Nahverkehr. Der Schaffner schickt sie zum Automaten oder Schalter, damit Sie ich ein Ticket besorgen.

Der Federation-Service muss nun aber nicht mehr "hinter" den anderen Server stehen, sondern kann irgendwo stehen, solange die Dienste selbst den vom Federation-Service ausgestellten Zertifikaten vertrauen. Das ist also der erste Weg in eine "Cloud"-Authentifizierung. Der Ablauf einer Anmeldung bei Office 365 ist natürlich etwas umfangreicher:

Aber der Aufwand lohnt sich, da der eigentliche Service sich nur noch den Request anschauen muss, um dieser ein gültiges Token enthält. Ohne Token kein Zugriff. Die ganze Verifizierung, AccountAngriffe, Multifaktor, Conditional Access etc. wickelt der Authentication-Service ab.

Stellen Sie sich mal vor, sie möchten Dienste aus der Cloud wie SAP, SalesForce, u.a. nutzen. Einen "NT-Trust bekommen Sie nicht hin aber dennoch möchten Sie ein "Single-SingOn" nutzen, dann können Sie einen Federation-Service bereitstellen, dem die anderen Dienste einfache vertrauen. Neben der vereinfachten Anmeldung gibt es zwei weitere wichtige Dinge

  • Kein Kennwort beim Dienstanbieter
    Der Dienstanbieter stellt nur seinen Service für die Zugriffe bereit, die ein gültiges und vertrauenswürdiges Token vorweisen können. Die Ausstellung steuern Sie auf ihrem Federation Server. Der Anbieter selbst hat also nie ein Kennwort. Damit ersparen Sie dem Anwender die pflege mehrerer Kennworte, dem Anbieter den Aufwand für ein Kennwort-Reset und als Lieferant des Token erkennen Sie auch sofort alle Anmeldeversuche und ggfls. Missbrauch.
  • Exit Management
    Der zweite Aspekt ist sogar noch wichtiger. Wenn ein Benutzer das Unternehmen verlässt, dann reicht es das interne Konto zu sperren. Wenn der Federation Server dann auch keine Tickets mehr ausstellt, sind alle Zugriffe auf andere Cloud-Dienste gleich mit blockiert

Das gilt sogar, wenn Sie als Mittelständler selbst einen Service bereit stellen und die Federation-Dienste ihrer Lieferanten und Kunden integrieren. Besonders interessant wird dies, wenn alle schon "AzureAD" verwenden und damit die Federation-Dienste von Office 365 als Basis für Anmeldungen zur Verfügung stehen.

Client und Server Apps

Bislang war es aber immer so dass der Anwender auf seinem Client seine Zugangsdaten eingeben musste oder vorhandene Credentials übertragen hat. Die lokale Applikation konnte dann "als Benutzer" mit dem Service kommunizieren. Der Service erkannte den Benutzer und gewährte ihm je nach Einstellung gewisse Berechtigungen. Die Berechtigungen waren aber an den Benutzernamen gebunden und nicht die Applikation. Aber es wäre doch interessant, wenn z.B. Outlook alles mit ihrem Postfach durchführen könnte während eine Serienbrief-App oder ein Kontaktmanagement nur auf ihre Kontakte zugreifen könnte.

Aber es geht noch weiter. Wer sagt denn, dass die Verarbeitung auf ihrem Computer stattfinden muss. In Zeiten von Apps und mobilen Geräten, die nicht immer online sind oder nur beschränkte Ressourcen haben, möchten Sie vielleicht bestimmte Funktionen auslagern. Vielleicht stört sie schon lange die "Installation" von Software eines Drittherstellers auf ihrem PC, wenn der Dritthersteller die Software doch auch in seinem Datacenter laufe lassen und warten könnte. Er bräuchte dann nur den selektiven Zugriff auf ihre Daten, um quasi mit ihrem Namen und in ihrem Auftragen die Daten zu verarbeiten.

Genau das Prinzip verbirgt sich nun hinter den App, die entweder mit ihrem "AppKonto" oder "OnBehalfOf" des Anwender auf die Daten zugreift. Sie geht dann direkt an den Token-Server, um sich ein Ticket zu besorgen. Hier am Beispiel von Graph (Graph API)

Die Applikation kann sich dabei eigenständig als "App" anmelden oder sich für den Anwender anmelden. Zumindest AzureAD lässt aber hier nicht jede App zu, sondern erwartet einen "Consent" durch den Anwender oder den Administrator.

Beispiel: Webseiten

Eine sehr einfache Form finden Sie z.B. auf https://education.microsoft.com, dem Portal für Lehrer und Schulen, auf denen es aber auch für IT-Pros interessante Informationen gibt. Wer sich hier anmeldet, bekam zumindest im April 2019 folgendes Fenster zu sehen: 

Ich habe mich nicht auf der Webseite selbst angemeldet, denn warum sollte ich meinen Benutzernamen und insbesondere mein Kennwort an eine mir noch nicht bekannte Webseite geben. Die Webseite wollte aber schon wissen, wer ich bin und hat mich daher auf die Webseite "account.live.com" für mein Microsoft Konto geleitet. Nachdem ich mir dort angemeldet habe, wurde ich von account.live.com gefragt, ob ich die gewünschte Information quasi "teilen" möchte. Ich räume dazu der Application als Benutzer die entsprechenden Berechtigungen sein, diese Daten abzufragen.

Beispiel: Thunderbird

Microsoft forciert die Umstellung der Cloud-Anmeldung auf "Modern Auth" für Exchange. Es ist schon länger angekündigt, dass Exchange Online die "Legacy Auth" irgendwann abschaltet:

In response to the COVID-19 crisis and knowing that priorities have changed for many of our customers we have decided to postpone disabling Basic Authentication in Exchange Online for those tenants still actively using it until the second half of 2021. We will provide a more precise date when we have a better understanding of the impact of the situation.
Quelle: https://techcommunity.microsoft.com/t5/exchange-team-blog/basic-authentication-and-exchange-online-april-2020-update/ba-p/1275508

Das bedeutet natürlich das auch IMAP4/POP3-Clients erweitert werden müssen. Die aktuelle Version von Thunderbird ist z.B. schon dafür vorbereitet und fragt bei der ersten Anmeldung nach der Zustimmung (Consent)

Wie es sich mit anderen IMAP4/POP3-Clients verhält, müssen Sie rechtzeitig klären. Das gilt insbesondere für automatische Abrufprozesse, wie diese bei Helpdesk, ERP, CRM oder Monitoring-Systemen gerne genutzt werden.

App-Berechtigungen verwalten

Das ist aber nur die einfache Version. Als Anbieter einer Dienstleistung kann ich meine Software und mein Dienst komplett in der Cloud betreiben und damit auf ihre Daten in ihrer Cloud zugreifen, wenn Sie mir entweder als Benutzer oder auch der Administrator allgemein die Rechte dazu einräumen. Welche Rechte ich einer App bereits eingeräumt habe, kann ich als Anwender selbst einsehen und verwalten.

  • Office 365 Konto/AzureAD
    Wer sich mit einem AzureAD Konto authentifiziert, kann dies unter der folgenden URL sehen und anpassen
    https://portal.office.com/account/?ref=MeControl#apps
    Sie können aber nur Apps verwalten, die sie auch selbst berechtigt haben. Im Firmenumfeld ist es häufiger der Fall, dass die Zustimmung durch Anwender unterbunden wird und ein Administrator zentral die Berechtigungen steuert. Das verhindert Missbrauch und Datenlücken. Siehe auch Phishing mit Consent-Anforderung
  • Microsoft Konto
    Die Consumer-Konten können eine ähnliche Funktion unter der folgenden URL erreichen.
https://account.live.com/consent/Manage

Sie sollten nicht überrascht sein, dass Sie die ein oder andere "App" hier schon finden. Meist in Verbindung mit mobilen Apps, die lieber mir dem eigenen Backend sprechen, welches dann mit ihren Daten kommuniziert. Hier ein Beispiel meines "Microsoft Kontos"

Die meisten Apps und Services nutzen das Microsoft Konto nur als "Identity Quelle" aber haben keinen Zugriff auf meine Daten. Sie sollten schon für jede "App" wissen, warum Sie welche Berechtigungen nutze. die meisten Apps möchten bei mir nur meine "Mailadresse" als Teil der Identifikation lesen. SyncBack hat aber auch die Rechte auf Dateien in meinem OneDrive zuzugreifen, weil ich damit einen alternativen Abgleich nutzen. Auch "Outlook" hat mehr Rechte, wie Sie hier sehen könnten.

Ein regelmäßiger Blick kann hier also nicht schaden.

Was kommt dann?

Eigentlich will niemand hunderte unterschiedliche Konten verwalten. Zumindest in Firmenumfeldern sind solche Konstruktionen nicht mehr sinnvoll zu verwalten und kaum nachzuhalten, wer wo wann Berechtigungen hat und sich von wo angemeldet hat. Kommt dann noch der Wunsch nach "Single SignOn" und die zusätzliche Absicherung mit Multi Faktor Authentifizierung (MFA) und Conditional Access, dann wird zumindest eine Firma immer den Weg gehen, dass ein Anwender auch genau ein "normales" Anmeldekonto hat. Administratoren bekomme natürlich eigene Anmeldekonten.

Es ist aber auch offensichtlich, das immer mehr Dienste gar nicht mehr auf dem Client des Anwenders oder den den Servern der Firma installiert werden, sondern ebenfalls als Cloud Service ihre Funktion bereit stellen. Dann kommen alle drei Dienste zusammen:

  • Der Anwender
    Er fordert eine Funktion an
  • Der Federation-Service
    Er stellt sicher, dass der Anwender sich anmelden und ein Token zur Authentifizierung hat.
  • Die Daten
    Der Speicher für ihre Daten, auf denen alle Zugriffe und Veränderungen passieren.
  • Die App
    Der Code, der mit ihrer Einwilligung sich als "App" vom Federation Server ein "App Token" anfordert und gegenüber dem Datenspeicher authentifiziert, ehe er mit den Daten arbeiten kann

Das ist eine etwas erweiterte Funktion, da Sie für bestimmte APIs eben nicht mehr einfach per "Benutzername/Kennwort" zugreifen können, sondern sich auch die verwendete Applikation entsprechend ausweisen muss. Und damit sind wie wieder bei Graph API und meiner ersten Applikation "Get-O365Usage".

Weitere Links