Zuul - Autenticazione gateway Api

Question

Desidero introdurre Zuul tramite Spring Cloud come gateway API di fronte a alcuni servizi.

Ho alcuni dubbi di progettazione in merito all'autenticazione. L'autenticazione verrebbe gestita da Spring Security, che precede Zuul nella catena di filtri del servlet.

La mia preoccupazione:

• Gateway si sedeva di fronte a molti servizi

• alcuni servizi può esporre gli endpoint che non richiedono l'autenticazione

• alcuni servizi potrebbero esporre endpoint che devono un ID sessione e alcuni con un token ", un valore opaco arbitrario (ad esempio il download di un file se si conosce un URL" difficile da indovinare ") Nel gateway API/Spring Security è possibile configurare tutti gli endpoint con i loro specifici requisiti di autenticazione.

In termini di gestione del gateway API:

• come si fa a far rispettare le attuali squadre di servizi di fornire le impostazioni necessarie per il servizio a valle?
• come si consentono modifiche frequenti delle impostazioni di autenticazione nel gateway (secondo le esigenze di servizio) senza dover interrompere l'intero gateway?

Grazie, Adrian

Answer 1

Stiamo usando sessione primaverile di replicare la sessione in tutti i nostri servizi che si siedono dietro un server Zuul Edge. Zuul autenticherà l'utente che popola le credenziali dell'utente e inserisce l'utente autenticato nella sessione. Questo viene quindi replicato su tutti i servizi e ciascun servizio è responsabile delle proprie regole e impostazioni di sicurezza. Quindi, in realtà, tutto ciò che Zuul sta facendo è guardare in alto alla sicurezza dell'utente e i servizi sul backend stanno applicando le regole di sicurezza che si applicano alle loro esigenze. In questo modo, è possibile modificare ciascun servizio in modo indipendente, rendendo il gateway un semplice proxy.

Un buon esempio di questo è nel tutorial di Dave Syers su Spring Security and an Angular JS app. Ho anche postato another question relativo a ciò che conteneva un esempio di come stiamo facendo anche questo, che potrebbe aiutare.

Answer 2

• Gateway si sedeva di fronte a molti servizi

Qual è la preoccupazione qui?

• alcuni servizi possono esporre gli endpoint che non richiedono l'autenticazione

Primavera di sicurezza ha una regola permitAll() accesso

• alcuni servizi possono esporre gli endpoint che hanno bisogno di una sessione Id e alcuni con un token ", un valore opaco arbitrario (per Esempio di download di un file se si conosce un URL "difficile da indovinare" Nel gateway API/Spring Security è possibile configurare tutti gli endpoint con i loro specifici requisiti di autenticazione .

Il tuo proxy Zuul può avere sessioni. Se si utilizza Spring Security OAuth 2.0 è possibile utilizzare ResourceServerSecurityConfigurer#stateless(false) e attivare le sessioni con HttpSecurity#sessionManagement().sessionCreationPolicy(...) per creare sessioni ogni volta che si riceve un token di accesso valido. Un cookie JSESSIONID verrà inserito nella risposta HTTP.

• come si fa a far rispettare le attuali squadre di servizio per fornire le impostazioni necessarie per il servizio a valle?

Non sono sicuro di aver capito la domanda qui, non ti voglio far rispettare i vincoli di sicurezza a livello di gateway (Zuul proxy) API? o stai cercando di avere "controlli di sicurezza doppia" sia sul proxy che sull'applicazione di destinazione?

• come si fa a permettere impostazioni di autenticazione frequenti cambiamenti del Gateway (come per le esigenze di servizio) senza dover fermare l'intera Gateway?

Zuul consente di aggiungere ZuulRoute s in modo dinamico in fase di esecuzione, se lo si utilizza come una libreria indipendente che è. Avvolto in Spring Security, il cui contesto è inizializzato una volta al momento dell'avvio ... Dubito che è possibile modificare facilmente la configurazione di sicurezza in fase di runtime.

EDIT seguenti precisazioni da parte della OP nei commenti: Se le squadre dovrebbero essere responsabili delle loro regole di sicurezza, avendo un sistema centralizzato porta è una contraddizione in base alla progettazione.

La mia interpretazione della filosofia del microservizio è che ogni applicazione è autonoma e responsabile del suo ambito funzionale completo e il controllo di sicurezza/accesso è parte di esso. È possibile verificare facilmente i token a livello di applicazione (effettuando una chiamata al server di autorizzazione o utilizzando JWT), con ogni applicazione che definisce quale ambito è richiesto per ciascuna risorsa. Spring Cloud dispone già di uno OAuth 2.0 starter oppure è possibile crearne uno facilmente se si utilizza il boot "semplice" Spring.

In questo modo è possibile distribuire singole app ovunque (cloud pubblico o server locali), senza dover fare affidamento su componenti upstream per la sicurezza o sincronizzare le distribuzioni della configurazione del gateway con altri team.

La cosa gateway API è una tentazione facile, ma non trascurare i rischi ei vincoli:

• non sarà in grado di garantire le chiamate interne
• Si dovrà fare affidamento sulla rete a monte componenti, e prendere in ingresso le applicazioni per scontato
• regole Advanced Access Control può diventare un mal di testa: come si fa a ottenere i permessi individuali dell'utente, ecc
• dovrete sincronizzare le modifiche alla configurazione con le altre squadre