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.

Zu der Zeit war man froh einen Server zu haben.

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. 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. 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.

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 z.B. bei einem Microsoft Konto bereits eingeräumt habe, können Sie unter folgender URL verwalten:

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