Come dovresti gestire l'autenticazione e condividere le informazioni degli utenti su microservizi?

Question

TLTR: cosa è un buon modo per comunicare attraverso i servizi per l'autenticazione e l'User Informazioni indipendentemente dalla posizione del server o della tecnologia utilizzata

sto cercando di conoscere microservices e io sono un po 'poco chiaro come dovrei avvicinarmi all'accesso alle informazioni degli utenti e controllare l'accesso con più servizi. Per favore fatemi sapere se mi sto avvicinando a questo completamente sbagliato.

Ad esempio, ho un servizio di base per le operazioni di Blog CRUD e un servizio per il caricamento e la memorizzazione di immagini e video. Non ho ancora fatto nulla con l'autorizzazione o gli utenti (tranne che nel mio blog ObjectID per i miei autori, commentatori, ecc.)

Voglio mantenere questo come separato possibile (per scopi di apprendimento più di qualsiasi altra cosa) e mentre al momento sto costruendo tutto in Node.js spero di essere in grado di scambiare dentro e fuori tecnologie diverse come nginx, un servizio java/go/python o un altro storage (attualmente mongo, ma vorrei poter passare a sql come opzione)

Come attualmente sono strutturati, ho entrambi i servizi creati come app Express.js e attualmente sto usando node-http-proxy per proxy ai servizi espressi (questo è solo per salvare con la configurazione di nginx per ora ma io non voglio neanche dipendere da nginx).

Come devo affrontare:

• utente autenticato o alcuni dei percorsi (ad esempio, quando si crea un nuovo post o l'aggiornamento/eliminazione) e non quando ottiene l'intervento ad Read (alla fine mi piacerebbe incorporare anche i ruoli)

• popolamento delle informazioni utente es. dal ID dell'utente memorizzati nel blog dell'autore e la sua sostituzione con le informazioni utente (in una singola applicazione ho potuto solo usare mangusta popolano

L'obiettivo principale è che vorrei mantenere l'Auth e degli utenti nei servizi separati che potrebbe essere chiamato in qualsiasi altro servizio e memorizzato in un altro DB, ad esempio se si trovavano su server fisici diversi.

qualcuno mi aveva suggerito che avrei potuto farlo utilizzando HTTP/S ma c'è un modo migliore per farlo e chiunque può indicarmi esempi di implementazione, Node.js sarebbe preferibile ma non essenziale

Questo Probabilmente richiede qualche registro di servizio ma sono un po 'perso su come sarebbe implementato

Answer 1

Un livello di autenticazione come propria applicazione si adatta abbastanza bene alla progettazione SOA. C'è un endpoint HTTP che non hanno accesso diretto al database micro-servizio che cosa SOA le migliori prassi è:

Per noi l'orientamento al servizio significa incapsulare i dati con la logica di business che opera sui dati, con l'unica accedere tramite un'interfaccia di servizio pubblicata. Non è consentito l'accesso diretto al database dall'esterno del servizio e non è prevista la condivisione dei dati tra i servizi .

- Werner Vogels, CTO di Amazon

riferimento al http://martinfowler.com/microservices/

Qual è uno strato di autenticazione o servizio e come si fa a server di conferma l'autenticazione è stata ancora stabilita? Un tipo di persistenza basata su client è un cookie HTTP che si aggancia strettamente a un nome di dominio, pertanto non è facile riutilizzare lo stesso cookie tra più domini senza un passaggio di autenticazione esplicito.

Se si è in grado di passare un certo tasto o intestazione http_request in grado di fornire l'autenticazione discreto, questo modulo è diventato una costruito nel nucleo Nginx a partire dalla versione 1.5.4: http://nginx.org/en/docs/http/ngx_http_auth_request_module.html

location /upload { 
    auth_request /auth; 
    ... 
} 

location = /auth { 
    internal; 
    proxy_pass http://auth_service.localhost; 
    proxy_pass_request_body off; 
    proxy_set_header Content-Length ""; 
    proxy_set_header X-Original-URI $request_uri; 
} 

L'endpoint accessibile attraverso http://auth_service.localhost (scegli il tuo URL) è isolato e ha un proprio database e fa solo una cosa: autenticare l'utente o meno. Un meccanismo può fare affidamento su una determinata chiave o intestazione o addirittura su un indirizzo IP. Per sopprimere a molte richieste successive è possibile memorizzare nella cache la risposta.

SOA è difficile, ma vi consiglio di leggere questo attentamente: https://www.nginx.com/blog/introduction-to-microservices/