Intra-Microserves authentication: Unterschied zwischen den Versionen
(Erste Überlegungen zum INTRA-Microservice Authentication) |
K (Formatierungen eingefügt) |
||
| Zeile 1: | Zeile 1: | ||
==Interne Authentifizierung== | |||
Identifizierter | ===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 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 | ===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. | Die Authentifizierung eines Microservice findet über Sluice statt. Hierfür kennt Sluice alle CA‘s dieser und signiert diese mit Hilfe einer Trust-Chain. | ||
| Zeile 30: | Zeile 30: | ||
HTTPS zwischen Microservices | ==HTTPS zwischen Microservices== | ||
Im Allgemeinen gilt, dass JWT nur verschlüsselt ausgetauscht werden sollen, was im Pool² über HTTPS realisiert wird. Dabei gilt: | Im Allgemeinen gilt, dass JWT nur verschlüsselt ausgetauscht werden sollen, was im Pool² über HTTPS realisiert wird. Dabei gilt: | ||
Version vom 7. Juni 2017, 12:12 Uhr
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.
