I microservizi dovrebbero essere utenti?

Stiamo cercando di determinare il modo migliore per autorizzare gli utenti in un'architettura di microservizi, garantendo al contempo che i microservizi abbiano autorizzazioni limitate. La nostra architettura utilizza un servizio di autorizzazione centrale per gestire l'emissione di token JWT.

Abbiamo i seguenti requisiti:

1. Gli utenti dovrebbero essere limitati a svolgere determinati ruoli. ad esempio, un utente dovrebbe essere in grado di creare / modificare / leggere solo i contenuti di sua proprietà.

2. I microservizi dovrebbero essere limitati alle sole autorizzazioni necessarie. ad esempio un microservizio che deve solo leggere i dati da un altro servizio dovrebbe essere esplicitamente vietato dalla scrittura di dati a quel servizio.

Ad esempio, supponiamo di avere un sistema in cui gli utenti possono caricare immagini su un servizio di archivio di immagini. Abbiamo un servizio di tagging che tagga automaticamente le foto con una posizione. Gli utenti possono solo CRUD le proprie immagini. Il servizio di tagging può leggere qualsiasi immagine dal servizio di archivio di immagini, tuttavia non dovrebbe essere in grado di modificare / eliminare.

Qual è un buon modo per ottenere quanto sopra usando i token JWT? Alcune soluzioni che abbiamo discusso sono:

1. Il servizio di archivio immagini espone 2 API, una disponibile esternamente (che consente l'accesso CRUD utente) e una disponibile internamente (che consente l'accesso interno di sola lettura). Sembra inflessibile: cosa succede se un altro servizio interno ha bisogno dell'accesso in lettura / scrittura a tutte le immagini (ad esempio uno che elimina automaticamente le immagini esplicite)?

2. Abbiamo impostato due autorizzazioni nel JWT dell'utente, uno è CRUD_OwnImages, l'altro è READ_ForAnalysis. Il servizio di tagging può vedere se l'utente dispone delle autorizzazioni READ_ForAnalysis e, in tal caso, effettuare la richiesta appropriata. Abbiamo un altro microservizio che verifica se l'utente ha CRUD_OwnImages per le operazioni CRUD sulle proprie immagini. Ciò pone la responsabilità su ciascun microservizio per garantire che l'utente sia limitato alle azioni richieste. Il negozio di immagini non ha modo di limitare ogni microservizio con questo approccio, quindi è potenzialmente esente da errori e soggetto a errori.

3. Diamo al microservizio di tagging il proprio utente, con READ_ForAnalysis come autorizzazione. Quindi, quando il servizio di tagging richiede immagini dall'archivio immagini, gli viene dato accesso, ma è vietato modificarle. L'utente dell'utente ha solo l'autorizzazione CRUD_OwnImages, quindi è in grado di recuperare e accedere solo alle sue immagini dal frontend. Se un altro servizio necessita di CRUD per tutti i dati, possiamo fornirgli CRUD_AllData o simili. Ci piace questo approccio poiché ogni servizio è ora responsabile dei propri dati (piuttosto che la logica viene duplicata su più servizi), ma cosa succede se il servizio richiede sia autorizzazioni utente che autorizzazioni microservizio? Possiamo inviare due token JWT (sia l'utente che il microservizio) in modo sicuro? C'è un modo per combinare le autorizzazioni in modo sicuro e inviarlo attraverso? per esempio

Il problema si aggrava se le informazioni dell'utente sono necessarie più a valle (2 o 3 microservizi di distanza). Supponiamo solo che spetti ai singoli microservizi limitarsi alle azioni di cui hanno bisogno e non renderlo esplicito?

In generale, quante più operazioni possibili dovrebbero essere legate a un vero utente umano. Obbliga le persone ad autenticarsi correttamente, spinge verso un'unica strategia di autorizzazione coerente ed è una parte importante della fornitura di una pista di controllo coerente.

E in generale, hai tre tipi di scenari con microservizi:

1. L'utente entra, carica una foto e deve essere taggata. Grande. Il servizio fotografico può semplicemente passare lungo il JWT al servizio di tagging (o viceversa a seconda della direzione della tua dipendenza) e se l'utente non ha i diritti per eseguire l'operazione secondaria, intraprendi l'azione appropriata (magari carica la foto senza un tag , forse restituire l'errore, forse qualcos'altro).

2. L'utente entra, carica una foto e deve essere taggata ... ma non ora.Freddo. Gestisci la foto ora come al solito. Successivamente, quando si verifica la codifica (gestione di eventi / messaggi, elaborazione dei comandi in stile CQRS, elaborazione periodica dei lavori, qualunque cosa) il servizio di tagging impersonerà l'utente (molto probabilmente utilizzando un segreto condiviso per richiedere un JWT personalizzato da auth) e quindi fare l'operazione secondaria per conto del richiedente originale (con tutte le sue autorizzazioni e limitazioni). Questo metodo presenta il solito problema con le operazioni asincrone in cui è difficile restituire errori all'utente se le cose non vanno per il verso giusto, ma se si utilizza questo modello per operazioni cross-service, l'avresti già risolto.

3. Alcuni sottosistemi devono fare cose al di fuori del contesto di un utente. Forse hai un lavoro notturno per archiviare vecchie immagini. Forse i tuoi tag devono essere consolidati ... In questo caso, probabilmente vuoi che ognuno di questi attori abbia il proprio pseudo-utente con autorizzazioni limitate e un ID univoco per l'audit trail.

Quale usare varierà a seconda del tuo scenario, delle tue esigenze e della tua tolleranza al rischio. E, naturalmente, si tratta solo di un insieme incompleto di generalizzazioni generalizzate.

Ma in generale, i microservizi stessi non dovrebbero essere utenti se possibile.