2015-06-25 13 views
7

ContestoMicroservices autenticazione

ho più servizi come:

  • utente (LDAP o Active Directory, ecc ...)
  • fatturazione
  • Pianificazione
  • ecc ...
  • Autenticazione

mi serve per collegare il mio microservices Utilizzando OAuth2.0, per principio, utilizzando il login/password standard (io uso i miei dati, e non gettint un terzo server gamba)

Problema

Secondo queste foto:

Fase 1

enter image description here

Fase 2

enter image description here

Come posso gestire il controllo access_token o il controllo di autorizzazione, nei miei altri servizi diversi authmicroservice?

risposta

1

c'è un tutorial e la descrizione del flusso di autenticazione nel microservices nel nostro attivatore, è a Scala - http://www.typesafe.com/activator/template/reactive-microservices (fonte: https://github.com/theiterators/reactive-microservices)


L'idea di base è: è necessario per convalidare l'autenticità del token di autenticazione per ogni richiesta è possibile:

- farlo in un proxy (il gateway)

- farlo all'interno del Microservice fatturazione


Cosa si tende a fare è: per convalidare Auth-token all'interno tutti i microservizi rivolti ai clienti.

- Manteniamo il token di autenticazione per le informazioni utente all'interno dell'istanza Redis.

- Il servizio client-facing chiede l'istanza Redis se questo blocco è valido

- Redis restituisce una stringa JSON che possiamo usare come un utente-dati per ulteriori autorizzazioni.

Così il flusso lato server assomiglia a questo

get("projects/"/Segment) { projectName => 
    getHeader("Auth-Token") { authToken => 
    Redis.get("auth:token:#{authToken}").map { userJson => 
     if(userJson("projects").include(projectName)) { 
     ...processSth... 
     Ok 
     } else { 
     Unauthorized 
     } 
    } 
    } 
} 
+0

Grazie per la risposta. La parte del tuo post che mi interessa davvero è la seconda, quando dici "Puoi farlo nel Gateway o in ogni servizio". Potete dettagliare un po 'di più con pubblicità e contro, per favore? : - D – mfrachet

+1

=> Separiamo l'autorizzazione dall'autenticazione. Il servizio di autenticazione dà "al frontend" "all'utente" un modo per dire "sì, sono io, è la mia sessione". L'autorizzazione dice all'utente X può fare qualcosa o non può. Mentre l'autenticazione viene eseguita da auth service/oauth, ecc., L'autorizzazione può essere collegata a regole aziendali molto più profonde e complesse. Diciamo che Gateway controlla se auth-token è valido e chiama i servizi di avvolgimento con l'intestazione HTTP X-UserId. Ora quei servizi hanno bisogno di se stessi per verificare se l'utente con un determinato ID può fare qualcosa. Ex. if UserId == project.ownerId project.save() –

+0

Quindi il proxy può essere un NGINX che ha qualche script che acceda Redis e controlla se il token è all'interno di redis e passa il valore del token da Redis in un'intestazione a servizi wrapper. Oppure può essere un normale microservizio. Questo può essere stratificato come richiesto, dato un dominio abbastanza complicato. –

0

E 'possibile creare il servizio Auth separato per fornire access_token come hai fatto vedere al punto 1. Ma in gateway API ogni servizio sarà necessario chiamare tale servizio di autenticazione per convalidare token.È meglio applicare il processo oauth all'interno dell'API Gateway che sto utilizzando anche per il mio prodotto e questo approccio è anche spiegato in molti articoli. guardiamo l'immagine qui sotto.

inlined image

In vista tecnico, potrebbe semplicemente una parte di codice (funzione) che gestisce intestazione di richiesta per verificare il token fornito come autenticazione oauth, che potrebbe trattate nel codice o accedendo proprio database prima inoltra le richieste all'endpoint del servizio.

È possibile seguire un metodo per fornire autenticazione, sicurezza e richiesta di dispacciamento all'endpoint tramite servizio di gateway API avanzato. C'è già una domanda a stackoverflow here, ma quello che ho trovato facile da seguire sono 3 o 4 serie di esercitazioni che troverai here

Ottieni un'immagine chiara dell'uso del gateway API prima di concentrarti sui microservizi su cui lavorare.

0

A seconda di come strutturate i vostri micro-servizi, potete anche trarre vantaggio dalla composizione.

Poiché si dispone già di un servizio di autenticazione, è possibile utilizzarlo nel servizio di fatturazione per verificare l'autenticità della richiesta prima di elaborarla.

Ad esempio, se si sta utilizzando una piattaforma come StdLib (usiamo questo in-house):

// Billing 
const lib = require('lib'); 

module.exports = function(params, callback) { 
    lib.user.isAuthenticated(params, function(err, user) { 
    if (err) return callback(err); 
    // Do stuff with user, process billing 
    }); 
}; 

questo potrebbe non essere una grande idea per voi, se si sta utilizzando sempre HTTP per comunicare tra le funzioni (poiché ciò aggiungerebbe probabilmente un buon 200-300ms alla tua richiesta). Ma StdLib carica alcuni servizi all'interno della stessa area e puoi accedervi essenzialmente come funzioni che risolvono quel problema (almeno, finora, che abbiamo visto).

4

Per gestire l'autenticazione in un'architettura di microservizi, è necessario avere un diverso punto di vista.

Ricordare che quando si lavorava su un monolite, si disponeva di un singolo processo di autenticazione.

Come esempio nell'app PHP, si trova l'utente in un database con le credenziali corrispondenti, quindi è stata creata una sessione a cui l'utente è "autenticato".

Con microservizi, il flusso di lavoro è un po 'lo stesso. L'unica cosa che cambia ora è che non si è in grado di aprire una sessione in servizi diversi. Inoltre, non è necessario ottenere l'utente autenticato. Devi solo essere sicuro di essere autorizzato a eseguire la chiamata corrente sui tuoi microservizi.

Grazie a oauth2, disporre di un access_token valido fornisce queste informazioni.

Questo dovrebbe rispondere alla parte di frontend. Nella parte backend (intendo dietro il gateway API), non devi gestire access_token perché non è rilevante per i microservizi. È possibile utilizzare un tasto funzionale per trovare qualsiasi informazione rilevante per l'utente all'interno di microservizi come un uuid per esempio.

Per ottenere un uuid durante l'utilizzo di oauth2, suggerisco di utilizzare anche openid connect. È utente con questo protocollo per gestire specifiche informazioni utente e ti dà accesso a un endpoint specifico "/ userinfo".

Spero che questo schema renda più chiara questa risposta.

enter image description here