Sicurezza gateway API (per architettura microservizi)

4

abbiamo iniziato recentemente con i microservizi, ma abbiamo alcuni problemi con l'implementazione del livello di sicurezza.

L'idea è che la richiesta arrivi al Gateway, il Gateway guarda all'intestazione dell'autorizzazione, convalida l'utente, crea il token JWT e poi invia la richiesta con informazioni sull'utente a un altro microservizio internamente. Il microservizio è raggiungibile solo internamente, quindi si fida del token JWT.

Nell'ultimo progetto, abbiamo inserito nel gateway le informazioni di base sugli utenti: è stato possibile registrarsi, accedere, reimpostare la password, ecc.

Ma il problema è che i microservizi di base stavano gestendo anche gli utenti, cioè aveva alcuni campi da convalidare, il che non è necessario per il gateway. Il processo di registrazione deve prima essere convalidato al microservice e se fosse ok, è stato registrato su entrambi - il gateway (password, email) e microservice (numero di telefono, nome, ...)

Il problema è quando fallisce su uno dei microservizi ma l'altro non lo sa. Quindi è registrato su gateway i.e., ma non su microservice. Fondamentalmente significa che devi preoccuparti delle "transazioni tra microservizi", che è qualcosa che non vuoi (i microservizi stateless sono i migliori da usare).

Anche alcune richieste, in particolare la registrazione, devono essere gestite in modo molto specifico, il che aumenta la base di codice e la complessità del gateway.

Stiamo pensando ad altre soluzioni:

1) La logica degli utenti verrà inserita nel gateway - è simile alla situazione attuale, ma non ci sarà alcuna convalida sul microservice di base, che lo rende senza stato. Il core microservice caricherà pigramente i nuovi utenti - quando apre il token JWT e non lo trova, lo creerà.

2) Avremmo due microservizi, uno per la registrazione e gli utenti stessi, l'altro per le altre funzionalità, se si trova il portatore di autorizzazione, il gateway chiederebbe al servizio clienti microservizio per i dettagli, se è ok, impacchetterà le informazioni in JWT token e invia il prossimo. La registrazione sarebbe appena passata nel servizio utente. Il microservizio di base sarebbe anche caricato pigramente.

3) Mettiamo le funzionalità del servizio utente nel microservizio principale stesso, il che renderebbe un approccio "più monolitico", ma il microservizio di base è strongmente dipendente dagli utenti. (si registrano in gruppi, acquistano prodotti, ecc.). Il gateway funzionerebbe come nel caso 2), chiederebbe al microservice di base le informazioni dell'utente e quindi comprimerà il token JWT e lo invierà successivamente.

Nota anche che stiamo sviluppando progetti di piccole o medie dimensioni. L'intero progetto solitamente utilizza da 1000 a 4000 uomini da zero alla produzione, il back-end stesso impiega 500-1500 ore di lavoro (stiamo sviluppando principalmente app mobili tra cui i server con cui stanno comunicando).

    
posta libik 20.10.2016 - 15:49
fonte

1 risposta

5

"The idea is that the request comes to Gateway, the Gateway looks to authorization header, it validates user, create JWT token and then sends request with info about user to another microservice internally. The microservice is reachable only internally, therefore it trust the JWT token."

Questo è sbagliato. il token JWT deve essere noto al client e inviato con ogni richiesta. Tutti i servizi devono convalidare il token e non solo fidarsi di esso.

Il tuo gateway API non dovrebbe avere alcuna logica. La sua semplice infrastruttura di rete

    
risposta data 20.10.2016 - 17:49
fonte

Leggi altre domande sui tag