Microservizi e autorizzazione

No, non stai utilizzando i token correttamente.

L'idea è che tu abbia un servizio di autorizzazione che emette token e servizi di risorse che possono convalidare il token e leggere le attestazioni in esso contenute. Quindi piuttosto che inoltrare il token al servizio di autenticazione ogni volta che il flusso dovrebbe essere come segue

• Cliente - > Auth: per favore dammi un token, ecco il mio nome utente e passa
• Auth - > Cliente: qui c'è un token che ho firmato con la mia chiave privata e contiene il reclamo "sono un agente contabile"

poi

• Cliente - > Risorsa: ciao, per favore dammi un elenco di account, ecco il mio token
• Risorsa - > Cliente: ho controllato la firma sul token utilizzando la chiave pubblica dei servizi di autenticazione. quindi so che posso fidarmi della tua affermazione di essere un agente contabile. Ecco l'elenco degli account

poi

• Cliente - > Risorsa: elimina questo account, ecco il mio token
• Risorsa - > Client: gli agenti dell'account sorry non sono autorizzati a eliminare account

Questo flusso impedisce al servizio Auth di diventare un collo di bottiglia per le prestazioni e lascia i vari microservizi per decidere se Claim X può fare l'operazione Y

Ruoli

Per indirizzare la tua seconda domanda su ruoli e permessi. Alla fine della giornata un servizio deve avere una serie di ruoli o permessi di cui è a conoscenza. ad esempio, devi codificare qualcosa del tipo:

If(users.Role != "RoleX")
{
    return "Access Denied!";
}

Piuttosto che avere un intero elenco di permessi diversi, "canEditAccounts", "canEditCustomers", "canDeleteAccounts" ... ecc. ecc., l'approccio moderno è invece quello di avere un elenco più breve di AccountingAgent dei ruoli che agisce essenzialmente come un insieme di permessi.

Se una terza parte consuma i tuoi servizi anche se dovranno utilizzare i ruoli che il servizio conosce. Ciò significa che sono bloccati con il livello di granularità che fornisci nei tuoi ruoli.

Ad esempio, se il tuo Accounting Agent fa troppo poco e il tuo Accounting Manager fa troppo per le tue esigenze di terzi, sei bloccato.

Un modo per aggirare questo è avere una mappatura dinamica tra ruoli e permessi. Chiedi al tuo servizio di conoscere le autorizzazioni e interrogare quali autorizzazioni ha un ruolo.

Puoi quindi consentire ai consumatori di terze parti di creare i propri ruoli, selezionando le autorizzazioni che desiderano avere ciascuna

Se non hai qualcos'altro come TLS per nascondere il token, renditi conto che se il token viene intercettato, chiunque può usarlo per fingere di essere quell'utente per la durata della sua validità. Personalmente, preferirei qualcosa di simile a un certificato client che non richieda il passaggio di segreti ed elimini la gestione delle sessioni dall'applicazione, ma non c'è nulla di sbagliato nell'approccio token purché tu comprenda e consideri i rischi.

Un vantaggio che vedo per avere un servizio separato che risponde a ciò che l'utente è autorizzato è che può essere sostituito se necessario. Quindi, se una terza parte vuole fare qualcosa di diverso, cambia il comportamento di quel servizio. Puoi semplicemente dire "ecco l'utente X" cosa può fare lui o lei? Questo disaccoppia completamente la struttura di autorizzazione dalle implementazioni del servizio.

L'uso di un servizio separato per gestire le autorizzazioni crea alcune potenziali sfide. Principalmente potrebbe diventare un singolo punto di errore e riceverà una richiesta per ogni chiamata a qualsiasi servizio. Dovresti essere in grado di gestirlo con il ridimensionamento orizzontale durante l'implementazione. È anche possibile incorporare il caching per evitare l'eccessiva chattiness.