Intra-Microserves authentication
Interne Authentifizierung
Def.: 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.
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.
