Intra-Microserves authentication
Innere Authentifizierung
Identifizierter:
Die Identität jedes Microservices wird über asymmetrische Verschlüsselung abgebildet. Hierbei verwenden wir den RSA Standard PKCS12, der im WWW weit verbreitet ist. Dies ermöglicht zum einen das Aufbauen einer HTTPS-Verbindung zwischen den MS, zum anderen können Tokens von MS eindeutig signiert werden.
Authentifizierung via Shared-Session:
Die Authentifizierung eines Microservice findet über Sluice statt. Hierfür kennt Sluice alle CA‘s dieser und signiert diese mit Hilfe einer Trust-Chain. Um das Prinzip des Loosely-Coupled nicht zu verletzen, 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 :
- 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.
- ← response 200 JWT
- Signatur FAIL → Sluice erstellt Error-Code
- ← response Error-Code
MS1 hat jetzt ein Token:
- Anfrage an Drops mit Token im HTTP-Header.
- Drops kennt Sluice und traut der Chain im CA und der Signatur des Tokens.
- 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:
- 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.
- MSn bekommt das CA von z.B Drops im JWT von Sluice. Somit kann er Drops für sich authentifizieren.
- Drops bekommt im HTTPS-Handshake das CA von MSn, was er dank der Trust-Chain und dem CA von Sluice überprüfen kann.
- Tokens die nicht zur HTTPS-Verbingung passen werden nicht beachtet.
