Sistema di autorizzazione e autenticazione per microservizi e consumatori

L'autenticazione e l'autorizzazione sono sempre argomenti validi

Cercherò di spiegarti come gestiamo le autorizzazioni nell'attuale servizio multi-tenant su cui sto lavorando. L'autenticazione e l'autorizzazione sono basate su token, utilizzando lo standard aperto Token Web JSON. Il servizio espone un'API REST a cui può accedere qualsiasi tipo di client (applicazioni Web, mobili e desktop). Quando un utente viene autenticato correttamente, il servizio fornisce un token di accesso che deve essere inviato su ogni richiesta al server.

Quindi vorrei introdurre alcuni concetti che usiamo in base a come percepiamo e trattiamo i dati sull'applicazione server.

Risorsa : qualsiasi unità o gruppo di dati a cui un cliente può accedere tramite il servizio. A tutte le risorse che vogliamo controllare, assegniamo un singolo nome. Ad esempio, disponendo delle prossime regole per gli endpoint, possiamo nominarle come segue:

product

/products
/products/:id

payment

/payments/
/payments/:id

order

/orders
/orders/:id
/orders/:id/products
/orders/:id/products/:id

Quindi diciamo che finora abbiamo tre risorse nel nostro servizio; product , payment e order .

Azione : è un'operazione che può essere eseguita su una risorsa, come, leggere, creare, aggiornare, eliminare, ecc. Non è necessario essere solo le classiche operazioni CRUD, è possibile avere un'azione chiamata follow , ad esempio, se vuoi esporre un servizio che propaga qualche tipo di informazione usando WebSockets.

Abilità : la possibilità di eseguire un action su resource . Per esempio; leggere prodotti, creare prodotti, ecc. È fondamentalmente solo una coppia risorsa / azione. Ma puoi aggiungere anche un nome e una descrizione.

Ruolo : una serie di abilità che un utente può possedere. Ad esempio, un ruolo Cashier potrebbe avere le abilità "leggi pagamento", "crea pagamento" o un ruolo Seller può avere le abilità "leggi prodotto", "leggi ordine", "aggiorna ordine", "elimina ordine".

Infine, a un utente possono essere assegnati vari ruoli.

Spiegazione

Come ho detto prima, usiamo Token Web JSON e le abilità che un utente possiede sono dichiarate nel payload del token. Quindi, supponiamo di avere un utente con i ruoli di cassiere e venditore allo stesso tempo, per un piccolo negozio al dettaglio. Il payload sarà simile a questo:

{
    "scopes": {
        "payment": ["read", "create"],
        "order": ["read", "create", "update", "delete"]
    }
}

Come puoi vedere nella dichiarazione di scopes , non specificiamo il nome dei ruoli (cassiere, venditore), ma solo le risorse e le azioni implicate sono specificate. Quando un client invia una richiesta a un endpoint, il servizio deve verificare se il token di accesso contiene la risorsa e l'azione richieste. Ad esempio, una richiesta GET per l'endpoint /payments/88 avrà esito positivo, ma una richiesta DELETE per lo stesso endpoint deve avere esito negativo.

• How to group and name the resources and how to define and name the actions and abilities will be a decision made by the developers.

• What are the roles and what abilities will have those roles, are decisions made by the customers.

Ovviamente, devi aggiungere proprietà extra al carico utile per identificare l'utente e il cliente (titolare) che ha emesso il token.

{
    "scopes": {
        ...
    },
    "tenant": "acme",
    "user":"coyote"
}

Con questo metodo, puoi mettere a punto l'accesso di qualsiasi account utente al tuo servizio. E, cosa più importante, non devi creare vari ruoli predefiniti e statici, come Ammin., Agenti e Utenti finali come fai notare nella tua domanda. Un Super utente sarà un utente che possiede un role con tutti i resources e actions del servizio ad esso assegnato.

Ora, cosa succede se ci sono 100 risorse e vogliamo un ruolo che dia accesso a tutti o quasi a tutti ?. Il nostro carico utile per i token sarebbe enorme. Ciò viene risolto annidando le risorse e aggiungendo semplicemente la risorsa principale nello scope di accesso.

L'autorizzazione è un argomento complicato che deve essere affrontato in base alle esigenze di ciascuna applicazione.

Penso che, indipendentemente da cosa, vorrai che i tuoi servizi accetti un token di autenticazione fornito da un servizio di autenticazione che scrivi per convalidare gli utenti. Questo è il modo più diretto / sicuro per prevenire l'uso improprio dei tuoi microservizi. Inoltre, in generale, se vuoi che un cliente abbia una buona esperienza, devi implementare personalmente le funzionalità critiche e testare accuratamente per assicurarti che le funzionalità che offri siano ben implementate.

Dal momento che tutti i chiamanti devono fornire ai microservizi le prove che sono stati autenticati, è possibile anche legare le autorizzazioni a tale autenticazione. Se offri la possibilità di legare un utente a un gruppo di accesso arbitrario (o ai gruppi se vuoi essere fantasioso, anche se le autorizzazioni aggiungono o sottraggono è più difficile da gestire qui.), Ci saranno meno domande dai tuoi clienti sul motivo per cui l'utente x è stato in grado di eseguire un'operazione indesiderata. In ogni caso qualcuno deve fare il controllo degli accessi per ciascun servizio, quindi potrebbe essere anche tu. È qualcosa che potrebbe essere codificato molto facilmente all'inizio di tutti i servizi ( if ( !TokenAuthorized(this.ServiceName, this.token) { Raise error } ). Si potrebbe anche farlo e tenere traccia dei gruppi di utenti stessi. È vero che devi avere un gestore di gruppi di autorizzazioni e utilizzarlo nell'interfaccia utente di gestione utenti (usa esistente / crea un nuovo gruppo per le autorizzazioni utente) Definisci definitivamente gli utenti legati a un gruppo quando modifichi la definizione, per evitare confusione . Ma non è un lavoro duro. Basta avere i metadati per tutti i servizi e legare la ricerca del mapping tra gruppo e servizio nella gestione del token auth.

Ok, quindi ci sono alcuni dettagli, ma ognuno dei tuoi clienti che vuole questa funzionalità dovrebbe codificarlo in ogni caso, e se supporti i permessi degli utenti a tre livelli, puoi anche semplicemente estenderlo gruppi di accesso per utente. Probabilmente un'intersezione logica tra le autorizzazioni del gruppo base e le autorizzazioni specifiche dell'utente sarebbe la giusta aggregazione, ma se si desidera essere in grado di aggiungere e rimuovere le autorizzazioni di base, delle autorizzazioni di amministratore, agente, utente finale, si dovrebbe fare l'indicatore di stato a tre usuale nei gruppi di autorizzazioni: Aggiungi permesso, Nega autorizzazione, Permesso predefinito e associa le autorizzazioni in modo appropriato.

(Come nota, tutto dovrebbe succedere su qualcosa come SSL o SSL a due vie se sei preoccupato per la sicurezza di entrambi i capi della conversazione.Se "perdi" questi token a un utente malintenzionato, se avesse crackato una password.)

La mia opinione è che qui hai due scelte.

• Se hai solo bisogno di avere un accesso configurabile essenzialmente alla stessa applicazione, allora i servizi controllano le autorizzazioni e offrono ai tuoi clienti un'interfaccia che consente loro di modificare le autorizzazioni assegnate a ciascun ruolo. Ciò consente alla maggior parte degli utenti di utilizzare la configurazione dei ruoli predefinita, che i clienti "problematici" possono modificare i ruoli o crearne di nuovi in base alle proprie esigenze.

• Se i tuoi clienti stanno sviluppando le proprie applicazioni, dovrebbero presentare la propria API intermedia. Che si connette al tuo come amministratore, ma controlla la richiesta in arrivo rispetto ai propri requisiti di autorizzazione personalizzati prima di chiamare i tuoi servizi

Considerazione sulla sicurezza

Se comprendo bene il tuo progetto, intendi delegare alcuni meccanismi di controllo dell'accesso alle risorse sul lato client, cioè un'app che consuma riduce gli articoli che un utente può vedere. La tua ipotesi è:

micro-services and their authorization system should not be bothered with clients needs, cause they are only consumers and not part of the system

Vedo qui due gravi problemi per gli affari seri:

• Cosa succede se alcuni utenti non autorizzati (ad esempio in uno degli impianti del tuo partner) eseguono il reverse engineering dell'applicazione client e scoprono l'API, eludono le restrizioni che la sua azienda ha messo sul client e utilizzano tali informazioni per danneggiare il tuo azienda ? La tua azienda chiederà il risarcimento dei danni, ma la società partecipante sosterrà che non hai fornito i mezzi per proteggere i tuoi dati sufficientemente bene.
• Solitamente, è solo questione di tempo in cui i dati sensibili vengono utilizzati in modo improprio (o il controllo rileva il rischio) e la tua gestione finirà per chiedere un controllo più stretto di tali dati.

Ecco perché consiglierei di anticipare tali eventi e occuparmi delle richieste di autorizzazione. Sei in una fase iniziale di reingegnerizzazione e sarà molto più facile tenerne conto nella tua architettura (anche se non li implementerai tutti) più tardi.

Se persegui la tua posizione attuale, consulta almeno il tuo responsabile della sicurezza delle informazioni.

Come implementarlo

Hai il trucco:

With this way, we would have to track only token scopes.

Ok, hai intenzione di usare alcuni token generici scelti dal cliente. Di nuovo una debolezza nei miei occhi, perché alcuni clienti possono essere fuori dal tuo controllo.

Non so se usi già JWT o se usi altre tecniche. Ma se usi JWT, potresti avere un token di identità che porta l'identità dell'utente (e anche un secondo token che identifica in modo sicuro l'app di origine, che potrebbe permetterti di differenziare il livello di fiducia tra client interni e client esterni ).

Poiché hai intenzione di optare per un'architettura di microservizi, vorrei suggerire amke la differenza tra il processo di gestione e autenticazione degli utenti (che dovrebbe essere eseguito come servizio dedicato) e il controllo degli accessi (che è specifico per ogni microservizio, e dovrebbe essere gestito localmente da ciascuno di essi) . Ovviamente alcuni client admin dovrebbero fornire una panoramica completa su diversi servizi, per facilità d'uso).

Anche qui c'è una risposta breve. Dovresti implementare tutte le funzionalità core che desideri offrire ai tuoi "clienti". Sembra problematico che i client aggiungano un comportamento così fondamentale come le autorizzazioni degli utenti stessi, dal momento che si sta già eseguendo l'autenticazione dell'utente; se lo lasci al cliente per implementarlo, potresti finire per "supportare" più implementazioni dello stesso codice di permessi. Anche se non lo si "possiede", ci saranno dei bug nel proprio codice e si desidera che i client abbiano la funzionalità che si aspettavano, entro limiti ragionevoli, in modo da supportare la risoluzione dei problemi che un client sta avendo. Supportare più basi di codice non è divertente.