I microservizi dovrebbero essere utenti?

Stiamo cercando di determinare il modo migliore per autorizzare gli utenti in un'architettura di microservizio, 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. per esempio. un utente dovrebbe essere in grado di creare / modificare / leggere il contenuto che possiede.

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

Ad esempio, supponiamo di disporre di 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 immagini con una posizione. Gli utenti possono solo CRUD le proprie immagini. Il servizio di tagging può leggere qualsiasi immagine dal servizio di archiviazione di immagini, tuttavia non dovrebbe essere in grado di modificare / eliminare.

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

1. Il servizio di archiviazione di immagini espone 2 API, una disponibile esternamente (che consente l'accesso utente a CRUD) e una disponibile internamente (che fornisce l'accesso di sola lettura interno). Sembra inflessibile - cosa succede se un altro servizio interno necessita dell'accesso in lettura / scrittura a tutte le immagini (ad esempio, quello che cancella automaticamente le immagini esplicite)?

2. Abbiamo impostato due permessi nel JWT dell'utente, uno dei quali è CRUD_OwnImages, l'altro è READ_ForAnalysis. Il servizio di tagging può vedere se l'utente ha le autorizzazioni READ_ForAnalysis e, in tal caso, effettuare la richiesta appropriata. Abbiamo un altro microservizio che controlla se l'utente ha CRUD_OwnImages per le operazioni CRUD sulle immagini dell'utente. Ciò pone la responsabilità su ciascun microservizio per garantire che l'utente sia limitato alle azioni che richiede. L'archivio immagini non ha modo di restringere ogni microservizio con questo approccio, quindi è potenzialmente flakey e soggetto ad errori.

3. Diamo al tagging microservice il proprio utente, con READ_ForAnalysis come permesso. Quindi, quando il servizio di tagging richiede immagini dall'archivio immagini, gli viene concesso l'accesso a quelle, ma è vietato modificarle. L'utente dell'utente ha solo l'autorizzazione CRUD_OwnImages, quindi è in grado di recuperare e ottenere accesso solo alle sue immagini dal frontend. Se un altro servizio ha bisogno di CRUD per tutti i dati, possiamo dargli 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 permessi utente che autorizzazioni microservice? Possiamo inviare due token JWT (sia dell'utente che del microservizio) in modo sicuro? C'è un modo per combinare le autorizzazioni in modo sicuro e inviarlo tramite? per esempio. il servizio di tagging può leggere tutte le immagini ma può anche scrivere le immagini dell'utente con la posizione?

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