Shared Session

Prinzip

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 übermittelt. Mit Hilfe dieser Id und dem Authorisation Code Grand Handshake, kann dann ein Json Web Token (JWT) an einen MS ü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.

Drops Event-System

Drops stellt neben dem Authorisation Code Grand Handshake noch ein Eventsystem bereit, über das verschiedene Informationen an die MS übermittelt werden können. Besonderes Augenmerk legen wir hierbei auf den Logout eines Nutzers und die Änderung von Nutzerdaten während einer laufenden Session. Hierfür verwendet Drops einfach HTTP-Post-Request, die durch das Sluice-Token authentifiziert werden. Ziel ist es hierbei veraltete Tokens zu erneuern oder als ungültig zu erklären.

Logout im Pool²

Der Logout eines Nutzers in einem auf Shared Session basierendem System, wie dem Pool², erfordert zusätzlichen Aufwand an Authentifizierungsdienst und die Kommunikation zwischen ihm und anderen MS. Zunächst einmal wird die Session_Id gegenüber Drops nach dem Abmelden des Nutzers ungültig gemacht. Drops gibt keine Authorizationcodes mehr zu dieser Id raus. Im nächsten Schritt, müssen bestehende Tokens ungültig gemacht und den jeweiligen MS der Logout mitgeteilt werde. Andernfalls könnte man mit dem Session-Cookie zwar keine Tokens anfordern, aber bestehende nutzen, die ein MS noch nicht verworfen hat. Drops nutzt hierfür das Event-System, um das Tupel aus Session_Id und Access-Token als ungültig zu erklären. Der MS verwirft dieses dann. Somit ist der Nutzer auch bei den MS abgemeldet.

Änderung von Nutzerdaten

Wenn sich die von Drops verwalteten Nutzerdaten, während einer Session, ändern, müssen die Access-Tokens neu ausgehändigt werden, da sie nicht nur Authentifizierungsinformationen, sondern gleich die Gesamten Nutzerdaten ausliefert. Diese Daten stimmen, nach der Änderung bei Drops, nicht mehr. In diesem Fall erklärt Drops über das Event-System die Access-Tokens für ungültig, lässt die Session_id aber bestehen. Dazu wird die Session_id mit einem neuen Autorisationcode ausgeliefert. MS kann jetzt an ein neues Token bei Drops anfragen, in dem er bei Schritt 4 im Authorisation Code Grand Handshake einsteigt. Das neue Access-Token beinhaltet die neuen Nutzerdaten.