SSO als Authentisierungslösung für Microservices

In einer Microservice-Architektur wird eine Applikation in ihre Kernfunktionen aufgeteilt. Diese Microservices werden dann unabhängig voneinander implementiert und deployed, und kommunizieren miteinander über sprachunabhängige APIs. Dies ermöglicht eine einfache und leicht verständliche Implementierung der individuellen Services und erlaubt kurze Entwicklungszyklen und die Entwicklung hochgradig skalierbarer und robuster Applikationen.

Grafik einer Microservices Architektur

Authentication bei Microservices

Der Benutzer muss also statt mit einem mit mehreren Systemen kommunizieren und sich dementsprechend auch auf mehreren Systemen autorisieren. Es gilt dabei zu vermeiden, dass ein Benutzer sich mehrfach authentisieren muss, indem er z.B. für jedes System nach einem Passwort gefragt wird. Über die einzelnen Microservices ist deshalb eine Art «Single Sign-On»-Lösung (SSO) notwendig.

Single Sign-On (SSO) in Microservices

Bei einer SSO-Lösung authentisiert sich ein Benutzer einmalig bei einem speziellen System, in der Regel «Authentisierungsserver» genannt. Dieser stellt die Identität des Benutzers sicher und generiert einen signierten Nachweis (Token) der Identität. Der Token wird von der Clientapplikation des Benutzers (bei einer Webapplikation der Browser, kann aber auch eine Mobile- oder Desktopapplikation sein) gespeichert und genutzt, um die Identität des Benutzers gegenüber den einzelnen Services ohne weitere Authentisierung nachzuweisen.

Für die Kommunikation zwischen Authentisierungsserver und Client hat sich dabei das Protokoll OAuth 2.0 und darauf aufbauend OpenID Connect (OIDC) durchgesetzt und stellt heute den Quasistandard dar. Das Format des Tokens selbst wird durch OAuth 2.0 nicht definiert, es hat sich jedoch weitestgehend die Verwendung eines signierten JSON Web Token (JWT) durchgesetzt.

Zustandslose oder zustandsbehaftete Übertragung

Um den Token vom Client auf den Microservice übertragen zu können, gibt es grundsätzlich zwei Möglichkeiten: Bei einer zustandslosen Übertragung wird der Token mit jeder Http-Anfrage mitgeschickt, technisch kann dies z.B. mittels Http-Headers oder Cookies umgesetzt werden. Bei einer zustandsbehafteten Übertragung hingegen wird der Token nur einmal an jeden Microservice geschickt. Dort wird, in der Regel mithilfe eines Session-Cookies, eine Benutzersession angelegt und der Token darin gespeichert. Jede weitere Kommunikation mit dem Microservice muss dann dieses Session-Cookie enthalten.

Bei einer zustandslosen Übertragung kann jede Anfrage unabhängig autorisiert werden. Die Microservices können so zustandslos und somit einfacher implementiert werden. Dies ist insbesondere bei Applikationen, die dynamisch skaliert werden, von Vorteil, da Instanzen eines Microservices einfach entfernt oder hinzugefügt werden können. Gerade wenn viele Benutzerinformationen benötigt werden, entsteht jedoch bei jedem Request ein gewisser Overhead, der mit einer zustandsbehafteten Übertragung verkleinert werden kann. Hier gilt es also, die spezifischen Bedürfnisse der Applikation zu berücksichtigen.

Einsatz von Open-Source-Lösungen

Die Verwendung von Standardprotokollen erlaubt es zudem, Open-Source-Lösungen oder andere Standardsoftware einsetzten zu können. Dies ist insbesondere bei den sicherheitsrelevanten Themen wie der Benutzerauthentisierung ein grosser Vorteil, da so einfach qualitativ hochstehende und geprüfte Lösungen zur Verfügung stehen. Als Beispiel ist hier insbesondere die Open-Source-Lösung Keycloak zu erwähnen, welche direkt verschiedene Authentisierungs- und Social-Loginverfahren (Bring Your Own Identity; z.B. Login mit einem Google- oder Facebook-Account) mitbringt und einfach erweitert und angepasst werden kann. Aber auch kommerzielle Produkte wie Okta oder Microsofts Active Directory Federation Services (ADFS) unterstützen OpenID Connect. Auf Client- und Serverseite existieren zudem Implementierungen für alle wichtigen Plattformen.

ti&m security suite

Die ti&m security suite bietet eine benutzerfreundliche Authentisierung, die mit einem «risk-based authentication»-Ansatz kombiniert werden kann. Diese Technologie wird in der Schweiz führend von ti&m angeboten. Durch das Verwenden von hardwarebasierten Sicherheitsmechanismen zur Aufbewahrung kryptografischer Schlüssel im Trusted Platform Module von modernen Smartphones kann in ti&m secure mobile eine sichere und trotzdem benutzerfreundliche Authentisierung angeboten werden. Durch den Einsatz von Standardprotokollen wie OpenID Connect kann die ti&m security suite einfach in bestehende oder neue Infrastrukturen integriert werden und bietet eine ideale Alternative zu selbstentwickelten und oft fehleranfälligen Sicherheitslösungen wie mTAN und garantiert eine starke und mobile Authentisierungslösung für moderne Multi-Channel-Plattformen.

Weiterführende Links

• OpenID Connect (OIDC)
• Microservice-Architektur-Blog von Martin Fowler
• Die ti&m security suite