Single Sign On mit OpenID Connect

Das Problem mit Passwörtern

Sich zahlreiche Passwörter merken zu müssen, ist keine gute Idee. Ich weiss, es gibt Passwort Manager, aber deren Verbreitung ist immer noch erschreckend gering. Zudem benötigt das Login in mehrere Systeme auch mit einem Passwort Manager etwas Zeit.

Also möchten wir unseren Kunden ein komfortables Single Sign On Erlebnis anbieten. Die Anmeldung in den Vertec Apps soll mit einem anderen System, welches bereits verwendet wird, gekoppelt werden. Im Umfeld unserer typischen Kunden muss man nach dem "anderen System" nicht weit suchen - wir bewegen uns in einer Microsoft-orientierten Umgebung, mit Office Applikationen und ihren Cloud Ausprägungen als "Microsoft 365".

Ginge es nur darum, verschiedene Passwörter zu vermeiden, dann hätten wir mit der Vertec LDAP Integration bereits seit ein paar Jahren eine Lösung bereit. LDAP macht aber eben nur das, es kümmert sich um die Prüfung von Login und Passwort. Echtes Single Sign On, also ohne mehrfache Eingabe von Username und Passwort, ist so nicht direkt möglich. Ausserdem gibt es neben dem guten alten Login mit Benutzername und Passwort mittlerweile eine ganze Menge weiterer Arten, wie ein User authentisiert werden kann.  Angefangen mit 2FA und biometrischen Verfahren bis zu Windows Integration und Hardware Tokens wird die Palette der Möglichkeiten immer breiter. Anbieter wie Microsoft setzen viele neuere Verfahren bereits um und es lohnt sich nicht, dies alles selbst zu implementieren.

Delegieren statt Implementieren

Die bessere Lösung ist es, die Authentisierung des Users gleich komplett zu delegieren. Und da wären wir beim eigentlichen Thema, der Integration mit einem Identity Provider, einem spezialisierten Anbieter für User Authentisierung. In Sachen Authentisierungs-Delegation gibt es zwei etablierte Standards: SAML und OpenID Connect.

• SAML ist im Enterprise Umfeld etwas weiter verbreitet, weil älter.
• OpenID Connect ist neuer und einfacher umsetzbar. Wir haben uns darum für OpenID Connect entschieden.

OpenID Connect ist eine Anwendung des OAuth2 Standards für Authentisierung. Das heisst, die wesentlichen Mechanismen entsprechen dem OAuth2 Authorisierungs Framework. Im Wesentlichen geht es bei OpenID Connect um die Beschaffung eines ID Tokens anstatt eines Accesss Tokens wie bei OAuth2. Das ID Token ist ein kryptographisch gesichertes Stück Daten, welches die Identität eines Users bestätigt.

Der SSO Aspekt wird über einen gemeinsam mit anderen Apps genutzten Browser erreicht, welcher via Cookies die Anmelde Session beim Identity Provider speichert. Solange der Browser die Anmelde Session kennt, ist keine Interaktion wie Passworteingabe notwendig und die Anmeldung erfolgt automatisch. Der Identity Server von Microsoft, nennt sich Azure AD (sozusagen die Cloud Version von Active Directory) und unterstützt OpenID Connect.

Umsetzung in Vertec

Mit unserer Integration konzentrieren wir uns für den Moment auf Microsoft als Anbieter. In groben Zügen sieht die OpenID Connect Integration in Vertec wie folgt aus:

• In Vertec wird auf einem Bearbeiter die eindeutige ID eines bestimmten Azure AD Users hinterlegt. Der Azure AD User entspricht dann in Vertec diesem Vertec Bearbeiter.
• Beim Start einer Vertec App wird die Authentisierung des Users an Microsoft delegiert (Azure AD).
• Der Microsoft Identity Server liefert nach erfolgreicher Authentisierung ein ID Token zurück.
• In Vertec können wir aufgrund der Eigenschaften des ID Token den zugeordneten Vertec User bestimmen und einloggen, natürlich nur nachdem wir das ID Token auf seine Gültigkeit geprüft haben.

Anstatt auf Username/Password basiert der Zugang zu Vertec also auf einem ID Token. Wie der User wirklich authentisiert wird, interessiert uns nicht, diesen Prozess haben wir ja delegiert. Damit wir dem ID Token vertrauen können, müssen wir zwei Dinge sicherstellen:

1. Das Token muss vom Herausgeber unseres Vertrauens (Azure AD) stammen und für unsere App bestimmt sein
2. Das Token darf bei der Übertragung nicht in falsche Hände geraten

Punkt 1 können wir durch Überprüfen der Signatur und der Angaben zu Herausgeber und Ziel-publikum des ID Tokens abdecken. Punkt 2 ist etwas heikler und hängt von der Art der beteiligten App ab.

Der OpenID Connect Flow

Wie geschieht nun die Umsetzung in den verschiedenen Vertec Apps?

Wir haben Web Clients, Desktop-, und hybride Clients wie Cloud- und Mobile App. OpenID Connect kommt aus dem Web Bereich. Die eigentliche User-Interaktion zur Authentisierung basiert immer auf einem Web Browser.

Der kritische Punkt ist, wie das ID Token vom Microsoft Server zur Vertec Applikation gelangt. Für die Übertragung der Daten vom Identity Provider zur App setzt OpenID Connect auf Browser Redirects. Der Identity Server weist in seiner Antwort auf eine erfolgreiche Authentisierung den Browser an, eine bestimmte URL der App aufzurufen. Bei der Vertec Web App ist dies eine Call-back URL auf dem Vertec Cloudserver.

Der Callback Aufruf erfolgt gesichert durch TLS (https://), die übertragenen Daten sind darum sicher und können nicht in falsche Hände gelangen. Die Abfolge der Aufrufe zwischen App, Browser und Identity Server wird gemeinhin "Flow" genannt.

Aktueller Stand der Dinge bei OpenID Connect ist der "Authorization Code Flow". Dabei überträgt der Identity Server in seinem Callback nicht das eigentliche ID Token, sondern nur einen Authorization Code, eine zufällige Zeichenfolge. Die Applikation verwendet dann diesen Code, um beim Identity Server das eigentliche ID Token anzufordern. Handelt es sich bei der Applikation um eine Webserver-basierte App, wird sie "Confidential Application" genannt, da das Token nur auf dem Server bekannt ist. Ein Angreifer hat kaum Chancen, das ID Token abzufangen, da dieses direkt von Server zu Server übertragen wird.

Schwieriger wird es bei Apps, welche nicht in einem normalen Web Browser laufen oder gar keine Serververbindung verwenden, z. B. der Vertec Desktop oder Cloud App. Bei diesen handelt es sich um native Windows Applikationen, ohne eigenen Webserver, die auf dem Client Rechner laufen.

Der Trick hier ist, als Callback URL eine custom URL anzugeben, für welche sich die App bei Windows registriert (z. B. ms-appx-web://some-callback). Damit kann der Identity Server auch eine native App mit einem Browser Redirect erreichen. Von der Sicherheit her ist das aber nicht optimal:

Während bei einem Webserver mit TLS per Zertifikat sichergestellt ist, dass es sich beim Empfänger des Callbacks wirklich um diesen Server handelt, kann eine Custom URL von jeder beliebigen App auf dem Rechner registriert werden, auch von einer Malware. Das heisst, die Daten im Call-back können mitgehört und missbraucht werden. Im Falle des Authorization Code Flows könnte ein Angreifer den abgehörten Code selbst verwenden, um ein ID Token anzufordern.

Hilfe von Pixy

Um diese Lücke zu schliessen, müssen Desktop Apps unbedingt ein erweitertes Verfahren nutzen: den Authorization Code Flow mit PKCE (englisch "pixy"). Dabei generiert die App beim Start des Authentisierungsvorgangs einen zufälligen, geheimen Verifier Code und sendet dem Identity Server einen daraus abgeleiteten Challenge Wert. Nur zusammen mit Verifier Code kann die App den erhaltenen Authorization Code beim Server gegen ein ID Token einlösen.

Da sowohl die initiale Übertragung des Challenge Werts an den Identity Server als auch das Einlösen des Authorization Code mit dem Verifier über https geschieht, ist die Sicherheit wieder gewährleistet. Seit der Einführung des Authorization Code Flows mit PKCE gilt der frühere "implicit" Flow, wo das Token direkt im Callback übertragen wird als unsicher und sollte nicht mehr verwendet werden, auch im Web Szenario.

Down to the code

Für die eigentliche Implementierung von OpenID Connect gilt die Faustregel für sicherheitsrelevanten Code: niemals selbst schreiben, sondern eine etablierte Library verwenden. Dies natürlich nur aus vertrauenswürdiger Quelle.

Die sicherste Variante der Umsetzung ist jene für die Web App. Dort wird der Authorization Code an den Server geliefert und das ID Token direkt auf dem Server beschafft. Der Browser sieht das ID Token gar nie.

Da unser Server auf dem Owin Stack basiert, setzen wird das Ganze mithilfe der Microsoft.Owin.Security.OpenIdConnect Package um, die sich um den ganzen Flow kümmert. Die Cloud App als native Windows Apps beschafft sich das ID Token clientseitig, wie oben beschrieben und sendet es dann via https an den Server. Die MSAL Library für .NET unterstützt das clientseitige Szenario und kümmert sich auch gleich um die Bereitstellung eines Browsers für die User Interaktion. Auf Serverseite überprüfen wir das ID Token mit Unterstützung der .NET Packages «System.IdentityModel.Tokens.Jwt» und «Microsoft.IdentityModel.Protocols.OpenIdConnect».

Der WAM Faktor

Damit SSO auch mit den Windows Apps funktioniert, brauchen wir für diese Apps einen Browser, in dem bereits eine Microsoft Anmelde Session existiert. MSAL schafft dies mit Unterstützung einer Windows eigenen Broker Komponente namens WAM (kurz für Windows Authentication Manager). Dabei handelt es sich um eine Art eingebauten Browser, der verschiedene Anmeldungen intern speichern kann. WAM wird von Windows selbst sowie von den Office Applikationen für Windows genutzt. Das Resultat ist, dass mit den in Windows konfigurierten App Konten auch für nicht Web-basierte Anwendungen SSO möglich ist.

Wrap Up

Die wesentlichen Punkte bezüglich SSO mit OpenID Connect lassen sich wie folgt zusammenfassen:

• OpenID Connect ist eine reife Technologie zur User Authentisierung mit guter Library Unter-stützung auf allen Plattformen.
• Sicherheitsmässig aktueller Stand der Technik ist der Authorization Code Flow mit PKCE, dieser wird von den meisten Libraries unterstütz und sollte eingesetzt werden.
• Der OpenID Connect Flow kann auf dem Client («native» Applikationen) oder auf dem Server (Web Apps) stattfinden. Beide Varianten gewährleisten die Sicherheit des ID Tokens. Die Server Variante ist wenn möglich vorzuziehen.
• Für Single Sign On mit «nativen» Applikationen gibt es unter Windows einen eingebauten Broker (WAM).

Next Steps

Die OpenID Connect Unterstützung in Vertec ist derzeit noch in Arbeit und wird allgemein verfügbar sein, sobald alle Apps, auch die Outlook- und Phone App, eingebunden sind. Die Umstellung einer Vertec Umgebung auf SSO mit OpenID Connect will gut überlegt und geplant sein. Neben den klaren Vorteilen, welche eine Anbindung an Azure AD als Identity Server bietet, muss berücksichtigt werden, dass damit auch neue Abhängigkeiten entstehen. Sollte die Microsoft Identity Server Infrastruktur mal ausfallen, ist eine Anmeldung an Vertec auch nicht mehr möglich.