Intra-Microserves authentication

Interne Authentifizierung

Im folgenden wird die Authentifizierung zwischen den verschiedenen Microservices (MS) thematisiert. Es geht somit darum, wie ein MS sicherstellen kann, dass ein Request tatsächlich von einem anderen MS stammt. Dies wird vor allem für die Absicherung sensibler Daten benötigt, die via Webservices bereitgestellt werden.

Identität eines MS

Die Identität jedes MS wird über asymmetrische Verschlüsselung abgebildet. Hierbei verwenden wir den RSA Standard PKCS12, welcher weit verbreitet ist. Dies ermöglicht zum einen das Aufbauen einer HTTPS-Verbindung zwischen den verschiedenen MS und zum anderen können Tokens (siehe Konzept zu Shared Session) von MS eindeutig signiert werden.

Authentifizierung via Shared-Session

Die Authentifizierung eines Microservice findet über den speziellen MS Sluice statt. Hierfür kennt Sluice alle CA‘s dieser und signiert diese mit Hilfe einer Trust-Chain. Um dem Prinzip des Loosely couplings zu folgen, werden die so erzeugten Tokens über Shared-Sessions ausgehandelt.

MS1 möchte gerne Daten von Drops bekommen:

• MS1 fragt Sluice nach einem Token für Drops, indem er ihm die gewünschten Kommunikationspartner( z.B. Drops) mitteilt. Authentifizierung mit eigenem KEY (PKCS12-RSA)

Sluice prüft Signatur von MS1 :

1. Signatur OK → Sluice erstellt ein JWT, in dem er alle Informationen zu den Kommunikationspartnern speichert. Dazu gehören: signiertes CA, Name, Permissions …. . Weite wird auch das CA von MS1 signiert hinterlegt.
2. ← response 200 JWT

1. Signatur FAIL → Sluice erstellt Error-Code
2. ← response Error-Code

MS1 hat jetzt ein Token:

1. Anfrage an Drops mit Token im HTTP-Header.
2. Drops kennt Sluice und traut der Chain im CA und der Signatur des Tokens.
3. Drops sendet Daten.

HTTPS zwischen Microservices

Im Allgemeinen gilt, dass JWT nur verschlüsselt ausgetauscht werden sollen, was im Pool² über HTTPS realisiert wird. Dabei gilt:

1. Sluice und MSn kennen sich und können sich auch gegenseitig anhand ihrer CA‘s authentifizieren. Somit können sie auch eine sichere HTTPS-Verbindung aushandeln.
2. MSn bekommt das CA von z.B Drops im JWT von Sluice. Somit kann er Drops für sich authentifizieren.
3. Drops bekommt im HTTPS-Handshake das CA von MSn, was er dank der Trust-Chain und dem CA von Sluice überprüfen kann.
4. Tokens die nicht zur HTTPS-Verbingung passen werden nicht beachtet.