SAML und Preauthentication

Auch wenn viele Dienste in der Cloud betrieben werden, gibt es weiterhin lokal gehostete Dienste, die von Anwendern in Internet aber auch von Diensten aus der Cloud angesprochen werden. Diese Seite betrachtet die Möglichkeiten von SAML-Tokens zu Preauthentication.

SAML und Kerberos statt Form, Basic, NTLM

Wer heute Webdienste aus dem Internet erreichbar macht, muss sich zwangsläufig Gedanken über Multifaktor-Authentifizierung, DoS-Attacken und Credential Phishing machen. Das ganze System muss zudem skalierbar, verteilbar und verfügbar sein. Auf der anderen Seite möchte man die Anwender nicht über Gebühr mit Anmeldedialogen und Rückfragen belasten. All diese und viele weitere Aspekte können Sie mit den Anmeldeverfahren der Vergangenheit nicht wirklich mehr erreichen.

Wenn Anwender ihre Anmeldedaten in einem Webformular (Form Based) oder im Browser (Basic/NTLM) eingeben müssen, dann ist dies nicht nur unbequem, sondern auch gefährlich. Es reicht wenn ein Anwender nur einmal bei der Eingabe nicht genau aufpasst, welche Webseite nun seine Anmeldedaten abfordert, damit ein Angreifer sich vielleicht schon mal als DomainUser in ihrem Netzwerk bewegen kann. Wenn der Client im internen Netzwerk oder per VPN eine Verbindung zum Domain Controller aufbauen kann, dann hilft der Einsatz von Kerberos, und notfalls NTLM schon dabei, dass Anwender sich nur genau einmal auf dem Client anmelden müssen. Beide Verfahren funktionieren aber nur eingeschränkt "im Internet" und schon gar nicht auf Systemen, die nicht mit dem Domain Controller kommunizieren.

Die Lösung sind hier "Tokens", auch unter dem Namen SAML, OAUTH, OAUTH2 etc., welche von einer vertrauenswürdigen Stelle ausgestellt, digital signiert und von dem angesprochene Dienst geprüft werden. Das Verfahren hat gleich mehrere Vorteile:

  • Alle Anmeldungen und Token Anforderungen laufen über den Token-Server
    Das ist ein zentraler Ort für die Kennwortabfrage, MFA/2FA-Lösungen, Protokollierung und damit auch DoS/Phishing-Schutz.
  • Sichere Tokens für den Service
    Die vom Token-Server ausgestellten Tickets enthalten neben der Identität auch zusätzliche Informationen zu Berechtigungen und sind digital signiert und ggfls. verschlüsselt
  • Service kann Token unabhängig und schnell prüfen
    Der vom Client angesprochene Dienst nimmt das Token, decodiert es (BASE64) und prüft die Signatur. Eine Rückfrage an den ausstellenden Server entfällt.
    Das geht alles sehr viel schneller als NTLM-Prüfungen und hilft gegen Angreifer
  • Kein Kennwort am Service
    Die Dienste müssen nie ein Kennwort abfragen, erhalten oder prüfen und sind damit besser geschützt.

Die gleichen Argumente können Sie natürlich auch als Nachteil aufführen. Zwei Punkte sind auf jeden Fall zu nennen.

  • Sie benötigen natürlich einen Authentifizierungsdienst
    Den können Sie in Form eines Windows ADFS Server oder Shibboleth selbst betreiben oder Sie nutzen z.B. die Entra ID-Dienste, die jeder Microsoft 365 Kunde schon hat. Firmen, die eher Privatpersonen als Zielgruppe haben, können z.B. Google-ID, Microsoft Konto, Facebook-Konto als Authentifizierungsprovider nutzen.
  • Als zweites muss die Zielanwendung natürlich mit SAML-Tokens umgehen können.
    Wobei hier einige Web Application Firewalls helfen können, indem diese von extern die Tokens anfordern und dann per Impersonation wieder klassisch den internen Dienst ansprechen.

Das Verfahren von SAML-Tokens ist aber nicht neu und im Grunde nutzen das Cloud-Dienste wie Google, Facebook u.a. schon sehr lange, um eben die eigentliche Authentifizierung von den Content-Servern z zu trennen.

SAML mit Exchange und Teams

Wenn Sie nun als Exchange OnPremises-Admin denken, dass SAML noch weit weg ist, dann irren Sie. Die Konfiguration von Exchange Hybrid aktiviert auf ihrem Exchange Server die OAUTH-Anmeldung. Sobald Exchange Online im Namen eines Benutzers aus Microsoft 365 auf Informationen in einem lokalen Postfach zugreifen möchte, muss sich Exchange Online authentifizieren. Da Exchange Online weder das Kennwort des Anwenders selbst hat und es auch kein "Dienstkonto" gibt, welches in ihrem lokalen AD mit Kennwort angelegt und in Microsoft 365 hinterlegt wurde, bleiben ja nur entweder "verborgene Geheimnisse" oder Tokens. Nur bei der Migration von Postfächer können Sie ein Dienstkonto angeben. Für Frei/Belegt-Zeiten, Mailtips u.a. kommen SAML-Tokens zum Einsatz. Dazu müssen Sie ihren Exchange OnPremises Server natürlich irgendwie "erreichbar" machen.

Der direkte Zugriff eines Anwenders mit Outlook auf den lokalen Exchange Server erfolgt in der Regel nicht per Tokens. Sie können dies natürlich auch aktivieren (Siehe Hybrid Modern Authentication (HMA) aber das nutzen eher wenig Firmen, so dass Anwender hier einfach die klassische Anmeldung per BasicAuth, NTLM oder Kerberos nutzen. Dies ist aber mit Exchange Online und Teams nicht möglich

  1. Teams Client zu Teams Backend
    Der Teams Client (1) verbindet sich nicht direkt mit ihrem Exchange OnPremises Postfach, sondern kommuniziert mit dem Teams Service (2).
  2. Teams Backend zu Exchange Online
    Wenn ein Anwender über die "Kontakt Karte" in Microsoft Teams den Status einer anderen Person ermittelt, dann liefert das Teams Backend den Verfügbarkeitsstatus und fragt parallel bei Exchange Online nach, welche Frei/Belegt-Zeiten im Kalender der anderen Person stehen.
  3. Exchange Online (3) zu Exchange OnPremises
    Exchange Online ermittelt den Standort des Postfachs und besorgt sich die Daten entweder aus dem Exchange Online Postfach oder aus dem lokalen Exchange Server.
  4. Firewall/WAF
    Zwischen der Microsoft 365 Cloud, dem Internet und dem internen Exchange Server steht natürlich eine Firewall-Lösung, die z.B. anhand der Quell-IP den Zugriff auf Microsoft 365 beschränken könnte. Ein Loadbalancer oder eine Web Application Firewall (WAF) kann aber auch die HTTPS-Verbindung aufbrechen und die Payload inspizieren.

Um genau diese Inspektionsmöglichkeiten geht es in den nächsten Abschnitten.

SAML Interaktiv oder Passiv

Wenn ein Client aus dem Internet einen Service erreichen möchte, der ein SAML-Token erwartet, dann müssen wir zwei prinzipielle Zugriffe unterscheiden:

  • Interaktiv Zugriff durch Mensch mit Browser
    In dem Fall kann der Service dem Client eine HTTP-Umleitung zum Authentifizierungsservice mit Rücksprungadresse senden. Nach erfolgreicher Anmeldung wird er vom OAUTH-Server mit dem Token wirder zum Service zurück gesendet.
  • Automatisierter Zugriffbr> Der zweite Fall sind nichtüberwachte Zugriffe von Diensten auf andere Dienste ohne aktive Mithilfe des Benutzers. Meist sind es "App-Permission" ohne MFA

In beiden Fällen spricht der Client aber zuerst einmal den Service "anonym" per HTTPS an und der Service muss nun eine Entscheidung treffen, wie er dem Client mitteilt, dass er ein SAML-Token erwartet. Die meisten Server nutzen dabei den "UserAgent" im Request. Wenn dort z.B. "Mozilla" auftaucht, dann geht der Server von einem "Browser" aus. Bei Zugrif per "Application" sollte der Client ein "Authorization: BEARER" mitsenden, damit der Service direkt weiß, dass der Dienst dies kann.

Client Anmeldung Rückantwort

Browser interaktiv

 
GET HTTPS://outlook.office.com/OWA
Authorization: <leer>
 
302 FOUND
Location: https://login.microsoftonline.com/...

PowerShellApp

 
GET HTTPS://outlook.office.com/EWS/Exchange.asmx
Authorization: bearer
 
403 AuthenitcationRequired
Authorization: bearer weitere Parameter

Im Browser Debugger können Sie dies anhand von Outlook Web App die 302 Antwort samt der "Location" sehr einfach sehen:

Für den Zugriff per Automation oder Applikation können Sie z.B. per PowerShell mit mein Script Test-Bearer einen Zugriff simulieren. Es sendet einfach eine anonyme Anfrage die URL mit der Angabe "Authorization: Bearer" und zeigt die Antwort an. Hier sehen Sie dann bei WWW-Authenticate die Rückantwort mit dem Verweis auf den Token-Service:

Es ist dann natürlich an der Client-Anwendung, diesen Wink zu interpretieren, sich ein Token zu besorgen und dann den Zugriff auf den Service mit dem Token als Authorization zu wiederholen. Wenn Sie z.B. auf einem Exchange 2019 Server mit Hybrid Bereitstellung und IIS Failed Request Tracing aktiv haben, dann sehen Sie ebenfalls die anonymen Zugriffe.

Etwas später kommt dann aber der komplette Request samt Bearer-Token:

Hier wird es dann aber interessant, wenn die Anfragen aus dem Internet auf einer Web Application Firewall landen, die per SSL-Inspection sich die Payload anschauen kann.

WAF und SAML Inspektion

In den seltensten Fällen werden Sie aber einen Service mit einem Bein direkt ins Internet stellen, sondern immer eine irgendwie geartete Firewall davor stellen, die gängige Angriffsmuster erkennt und unterbindet. Wenn Sie ihre WAF so konfigurieren, dass Sie die TLS-Verbindung terminiert, dann können Sie per TLS-Inspection nicht nur die Payload der Aufruf prüfen, sondern auch die Header. Ich habe dazu als regulärer Benutzer in Teams einen Termin geplant und parallel dazu auf dem lokalen Exchange Server eine Hybrid-Bereitstellung die eingehenden Requests mitgeschnitten. Natürlich habe ich hier auch einen Bearer-Token bekomme, der wie folgt aussah:


Auszug IIS Trace. Token unkenntlich gemacht.

Auch wenn das Token nur 8 Stunden gültig ist und daher eine Klartextversion kein Risiko darstellen sollte, möchte ich einfach sie nicht verleiten, dass Sie eigene Tokens irgendwo im Klartext veröffentlichen. Ich kann das Token aber decodieren (Siehe auch Bearer Decoding) und sie sehen, dann, dass es für mich als Person ausgestellt ist.

Sie sehen hier schon Nummern wie "00000002-0000-0ff1-ce00-000000000000" und mit "de21-*" die GUID des hier verwendeten Tenants. Wer noch genauer hinschaut, erkennt aber auch noch das Feld "actortoken", welches ich auf die gleiche Weise decodieren kann.

Auch hier erscheint wieder 00000002-0000-0ff1-ce00-000000000000 und wer nach der Nummer sucht, findet sehr schnell, dass es sich um die Identität von Exchange Online handelt.

All diese Informationen sind als öffentlich und einfach zu decodieren. Eine entsprechend konfigurierte WAF könnte als unabhängig von den IP-Adressen eines Clients im Internet einfach generell die SAML-Tokens prüfen, die ein Client aus dem Internet an die WAF sendet, um über den Reverse Proxy dann den Service im Backend zu erreichen.

Ich bin aktuell (Jun 2024) noch erstaunt, dass so wenige WAF-Installationen diesen Weg nutzen und stattdessen weiter auf IP-Adressen setzen.

SAML Authentication auf Web Application Firewall

Der nächste Schritt wäre dann, dass die WAF nicht nur die eingelieferten SAML-Tokens prüft, sondern direkt selbst die Authentifizierung erzwingt und dann ihrerseits die Anfragen zum Backend Service weiterreicht. Schon früher haben Firmen ihre Webdienste hinter einer Web Application Firewall (WAF) veröffentlicht, die eine "Preauthentication" übernommen hat. Der Anwender aus dem Internet landete auf eine Portalseite, welche dann erst einmal Benutzername und Kennwort und vielleicht noch eine zweite Information (Token etc.) abgefragt hat, ehe sie dann die Zugriffe zum eigentlichen Service erlaubt hat. Das kann sie heute auch noch aber sie muss sich nicht mehr selbst um die Authentifizierung kümmern, sondern könnte ganz einfach selbst diese Anmeldung an einen Token-Server delegieren.

Mittlerweile dürften wohl die meisten halbwegs aktuellen Web Application Firewalls diesen Weg kennen Ich liefere ihnen hier exemplarisch zwei Bilder eines KEMP Loadbalancers:

Zuerst muss ich für den veröffentlichten Service die Authentifizierung definieren. Hier sehen Sie z.B., dass ein späterer Zugriff ohne Bearer-Token zu Microsoft umgeleitet wird

Natürlich muss ich dazu auch in Entra ID eine entsprechende App registrieren, damit Entra ID auch weiß, welche Tokens es ausstellen muss. Zusätzlich muss ich in den ESP Optionen ebenfalls noch ein paar Einstellungen zu SAML machen.

Es sind noch ein paar weitere Einstellungen erforderlich aber letztlich soll das Beispiel nur zeigen, dass eine Web Application Firewall bei einem Zugriff von Extern einfach die Existenz eines Bearer-Tokens erzwingen und den Client zum passenden Token-Server leiten kann.

SAML und Delegation

Wenn der Client dann schon einmal an der WAF authentifiziert ist, dann können Sie wieder weitere Möglichkeiten einer Delegierung nutzen, damit sich der Benutzer am nachgelagerten Backend nicht erneut anmelden muss. Wobei nicht alle Verfahren möglich ist. Ich versucht mich mal an einer Liste:

Anmeldeverfahren im Backend

Nutzbar

Beschreibung

Basic

Wenn der nachgelagerte Webservice wirklich nur eine Anmeldung per Benutzername und Kennwort erlaubt, dann ist kein Single Sign On möglich. Die WAF hat ja nur ein Token, indem der Benutzer Name etc. Hier wird der Anwender sicher erneut eine Anmeldung durchführen müssen.

NTLM

Auch eine Anmeldung per NTLM wird knifflig, da sich die WAF ohne Kennwort nicht am DC anmelden kann.

Kerberos

Delegierter Zugriffe ist die Paradedisziplin von Kerberos. Über die Funktion "Kerberos - Constraint Delegation" können Sie als Administrator einem Konto das Recht einräumen sich ein internes Kerberos-Ticket für den Zugriff auf einen Dienst zu geben. Sie können damit dem Dienstkonto des WAF erlauben, sich nach Authentifizierung des Anwender am WAF per Bearer oder anderer Verfahren ein Kerberos-Ticket nach intern ausstellen zu lassen.

FormBased

Die Anmeldung an einem Formular ist genauso eingeschränkt die Basic-Auth. Die WAF hat keine Daten zum eingeben. Ein Sonderfall wäre natürlich, wenn die WAF das extrahierte SAML-Token quasi als "FORM POST" an die nachgelagerte App senden könnte und diese das Token auswertet. Das könnte z.B. bei SharePoint OnPremises möglich sein.

SAML

Wenn der nachgelagerte Service auch die gleichen SAML-Tokens versteht, dann spricht nichts dagegen, dass die WAF den Request einfach mit dem "Authorization: Bearer xxx"-Header durchreicht. Das ist natürlich die ideale Lösung

Header/Payload/Cookie

Es gibt interne Webdienste, die gar keine eigene Authentifizierung durchführen, sondern einfach die Identität des Clients als zusätzlichen Header erwarten. Das ist gar nicht mal so selten und eine entsprechende WAF könnte aus dem SAML-Token einfach das Feld UPN oder SMTP als HTTP-Header in den Request an das nachfolgende System addieren. Es versteht sich von selbst das das nachfolgende System nie von Client direkt erreicht werden darf, welche mit dem Wissen auch entsprechende Header setzen könnten.

Wenn ihre Clients sicher per SAML an einem Reverse Proxy authentifizieren, dann können Sie den Anwender nur nur mittels Kerberos - Constraint Delegation direkt zu einem Backend Server authentifizieren, sondern auch SAML nutzen.

SAML und Session-Cookies

Ganz allein auf die Überprüfung von SAML-Token in einem Request können Sie sich natürlich nicht verlassen. Dam einem erfolgten Verbindungsaufbau und der Authentifizierung schalten viele Produkte auf eigene Absicherungen um. Ein SAML-Token ist meist nicht nur einige Stunden gültig sondern schon aus Sicherheitsüberlegungen möchte man nicht, dass in jedem Request das SAML-Token übertragen wird, selbst wenn die Verbindung per TLS abgesichert ist.

Daher senden viele Services nach erfolgter Anmeldung z.B. ein Cookie, welcher vom Client immer wieder mit gesendet und vom Server regelmäßig erneuert wird. Der Server erspart sich so die andauernde Prüfung von SAML-Tokens. Das Session-Cookie kann noch weitere Informationen zum Client erhalten und vor allem eine von Server vorgegebene Gültigkeit besitzen. Zudem erspart sich der Service dem Client nach Ablauf des SAML-Token so die Aktualisierung durch eine Reauthenticate am OAUTH Server.

Für eine WAF bedeutet dies aber, dass Sie "Session Aware" sein muss, d.h. durchaus die SAML-Tokens in einem Request auf ihre Gültigkeit prüfen sollte aber dann die Sitzung als legitim ansieht, auch wenn in nachfolgenden Transaktionen dann kein SAML-Token mehr enthalten ist. Einige WAAF-Produkte lösen dies z.B. indem Sie eigene Header oder Cookies mit einfügen, die vom Client wieder zurückgesendet werden. Insofern ist auch diese Herausforderung schon lange gelöst.

Zwischenstand

Den ersten Abschnitt hatte ich schon mit "SAML und Kerberos statt Form, Basic, NTLM" überschrieben und spätestens jetzt sollten Sie verstanden haben, dass SAML-Token eine sehr leistungsfähige Authentifizierung sind. Web Application Firewalls können sehr schnell die SAML-Tokens prüfen und DoS-Attacken einfach vom Service abhalten. Zudem konzentriert sich die eigentliche Anmeldung auf den OAUTH-Server, der alle Anmeldungen konzentriert seht und damit viel einfacher die Konten bei Angriffen auf das Password schützen kann. Der Service selbst muss, anders als bei BTLM, BasicAuth o.ä. auch nicht mehr mit dem Authentication Service sprechen. Im Prinzip sind SAML-Tokens die Weiterentwicklung von bislang intern genutzten Kerberos-Tickets.

Je mehr internen Dienste aber auch SAML-Token verstehen oder über eine WAF mit Delegation mit SAML-Tokens genutzt werden können, desto interessanter ist der Einsatz eines OAUTH-Service wie z.B. Entra ID, da damit erweiterte Schutzfunktionen möglich werden.

Wann stellen Sie auf SAML um oder sagen ihrer WAF, dass Sie eingehende SAML-Token, z.B.: von Exchange Online Hybrid oder Teams prüft?

Weitere Links