Shared Session

Nutzer müssen durch beinahe alle Microservice identifiziert werden können. Damit nicht jeder MS eine eigenen Authentifizierung implementieren muss und damit die Wartbarkeit des Gesamtsystem erschwert und außerdem den Nutzern kein eigener Login für jeden MS zugemutet wird, soll eine Shared Session implementiert werden.

Nutzer senden Informationen zur Authentifizierung ("Credentials") an Drops, um eine Session zu erhalten. Bei erfolgreicher Authentifizierung gegenüber Drops, wird eine Cookie mit Session_id an den Client/MS übermittelt. Mit Hilfe dieser Id und dem Authorisation Code Grand Handshake , kann dann ein Json Web Token (JWT) an den Client übermittelt werden. JWTs können technologieübergreifend zur Authentifizierung eingesetzt und im HTTP Header Authorization: Bearer <token> weitergegeben werden. So ist es möglich das von Drops generierte Token an andere MS weiterzugeben. Dieses Vorgehen implementiert die Shared Session.

Empfängt ein MS einen Request ohne JWT, muss der MS einen HTTP Redirect zu Drops vornehmen, falls der aufgerufene Pfad nicht ohne Authentifizierung verfügbar ist.

Shared Session sind, was Datenschutz und Missbrauch des Netzwerkes angeht, eine sensible Stelle in der Pool² Architektur. Da in den JWT Nutzerdaten direkt gespeichert werden bieten diese ein interessantes Ziel für Angriffe auf Pool². Aus diesem Grund bietet es sich an für die Handshakes, die für den Austausch der Tokens verwendet werden und auch für die Verwaltung der Tokens bei den Clients, auf bekannten Standards zurück zu greifen. Im Drops Prototyp bereits eingesetzt und für unsere Zwecke besonders gut geeignet ist das OAuth Protokoll . In OAuth werden vier verschiedene Handshakes beschrieben, wobei der Authorisation Code Grand hier am besten für uns geeignet ist.

Authorisation Code Grand im Pool²

Zentrale Rolle für die Shared Session ist der MS Drops, der als OAuth Provider fungiert. Für die Anbindung eines MS an Drops ist lediglich die Registrierung bei Sluice nötig, die beim Initialen Deployment vorgenommen wird.

Die Access-Tokens werden nur zwischen MS und Drops ausgetauscht und nicht wie anfänglich überlegt, im Browser des Nutzers gespeichert. Dies hat offensichtliche Vorteile bei Sicherheitsaspekten und ermöglicht uns eine bessere Granulierung der Zugriffsrechte sowie der Datensätze, die über ein Token an einen MS übergeben werden.

Damit ein MS überhaupt an ein Token kommt, muss sich ein Nutzer gegenüber Drops Authentifizieren. Drops übergibt dem Nutzer (b.z.w. seinem Browser) einen Cookie mit einer Session_id, die die Aktuelle Login-Session des Nutzers beschreibt. Diese Session_id ist im ersten Schritt nur Drops bekannt. Sollte der Nutzer jetzt auf einen Microservice zugreift, der die Session_id nicht kennt, aber ein Token von Drops für seine Funktionen benötigt, beginnt der Authorisation Code Grand Handshake:

Der Handshake findet zwischen Drops, dem Browser des Nutzers und einem MS (hier MS1) statt. MS1 braucht ein Token.

1. Browser greift auf MS1 zu, mit seiner Session_id.
2. MS1 kennt die Session_id nicht und redirected daher zu Drops.
3. Drops kennt die Session_id und verbindet diese auch mit einem Nutzer. Er redirected wiederum zu MS1, wobei im Query-String der HTTP-Anfrage ein Autorisationcode mitgesendet wird. Der Query-String ist durch die HTTPS-Verbindung verschlüsselt.
4. MS1 sendet diesen Code weiter zu Drops, wobei er sein Sluice-Token in dem Authentifizierungsfeld des HTTP-Headers mitgeschickt wird. Das Token von Sluice Authentifiziert MS1 als legitimer Oauth-Client.
5. Drops erstellt jetzt ein Access-Token und sendet dieses an MS1.
6. MS1 speichert das Tupel aus Session_id und Access-Token.

Nach diese Handshake kennt MS1 die Session_id und kann mit dem Access-Token Nutzerdaten abrufen.