Vado per un capriccio e presumo che tu stia utilizzando un tipo di servizio web. Per favore correggimi se sbaglio.
Ci sono molti fattori che potrebbero avere un ruolo nel modo in cui questo "può" essere fatto perché ci sono vari modi. Tipicamente con l'architettura basata sui micro servizi, ho fatto quello che ritengo sia un approccio semplice alla comunicazione tra i vari servizi.
Un bus di messaggistica è un buon modo per iniziare. In termini di autenticazione, avrei un'autorità centrale (un servizio che si occupa esclusivamente dell'autorizzazione / autenticazione) o ogni servizio convalida un messaggio indipendente da un'autorità centrale (eliminando così il potenziale di una singola fonte di errore).
Servizio autorità centrale
- Ogni messaggio pubblicato sul bus può avere un token o una stringa / hash arbitraria (vedere Token Web JavaScript) che contiene o rappresenta i dati. Prendi in considerazione il passaggio come valore HEADER di X-Authorization. Lascerò le implicazioni sulla sicurezza fuori da questa risposta. Se vuoi archiviare dati reali o riferimenti a dati all'interno del token (e memorizzare i dati effettivi in luoghi più sicuri come un database) è completamente a te e ai tuoi requisiti aziendali.
- Quando un servizio sottoscritto da un determinato canale riceve il messaggio, in base al consumo o a una chiamata API dal broker dei messaggi, puoi prendere il token di autenticazione / autorizzazione e fare una chiamata al servizio di autorità che convaliderà il token e restituisce una risposta di conferma 200 o una risposta 401/403. Spetta al servizio dell'autorità decidere, convalidare e dare un senso a questo token in base alle regole aziendali.
- In base alla risposta restituita dal servizio di autorità di cui sopra, il microservizio che consuma può continuare o interrompere l'esecuzione. In sostanza hai creato un firewall remoto. Un token Web JavaScript contiene una firma firmata dal servizio di avvio. Questo può essere firmato con una chiave privata o addirittura con un certificato. Il controllo della validità di questo token o risorsa è l'obiettivo finale.
Come detto sopra ci sono molti modi diversi per farlo e questo è solo uno dei molti approcci. Ecco un altro ...
Verifica dell'autenticità di un messaggio a livello di servizio
Invece di affidarsi a un singolo punto di autorità, è possibile anche firmare un token per certificato (certificati con firma token) o una chiave segreta condivisa tra tutti i micro servizi che consumano. Ogni micro servizio consumerà il messaggio e ne verificherà la validità tentando di decodificare la firma (verificando il certificato o utilizzando la chiave privata, si spera nascosta in un ambiente da qualche parte e non nel codice) nel messaggio prima di consumarlo ed eseguire il ruolo rispettivo del micro servizio. Questo è simile al metodo sopra meno la necessità di un'autorità centrale. Ci sono tuttavia degli svantaggi in questo metodo.
-
Ogni volta che aggiorni il codice per convalidare i messaggi, sarà necessario farlo su ogni messaggio che consuma un servizio (immagina di dover applicare una hot-fix di sicurezza mission critical a diversi servizi in produzione!)
-
Riduce la modularizzazione - ora i tuoi servizi fanno più dello scopo previsto e devono gestire l'autenticazione, l'autorizzazione e realizzare la sua funzionalità progettata
Potresti anche configurare il tuo servizio in coda in modo tale che i tuoi micro servizi non debbano essere consumatori , ma il tuo broker può fanout o avviare chiamate API agli endpoint configurati dei tuoi micro servizi . Personalmente non ho configurato i miei servizi di coda per farlo (RabbitMQ / AWS SQS - > Lambda), ma alcuni miei amici lo hanno.
Speriamo che questo aiuti alcuni.