2015-05-27 20 views
6

Sto creando un'applicazione Web Intranet costituita da un frontend angolare e un backend Node.JS. L'applicazione deve utilizzare Active Directory aziendale per l'autenticazione e l'autorizzazione.Utilizzo di JWT con autenticazione Active Directory nel backend NodeJS

Sto valutando come implementarlo al meglio in modo sicuro. Sto pianificando di utilizzare lo Active Directory node module per comunicare effettivamente con l'annuncio per autenticare quando l'utente esegue l'accesso e per verificare l'appartenenza al gruppo di sicurezza per alcune azioni limitate, ecc.

Tuttavia, non sono sicuro di quale sia il modo migliore per autorizzare i miei endpoint back-end. Il modulo AD non offre alcun token/ticket, anche se suppongo che Kerberos venga utilizzato per l'effettivo processo di autenticazione. In altre app autenticate che ho sviluppato ho generato un jsonwebtoken quando l'utente effettua il login e poi ha passato e verificato quel token in ogni percorso di backend, è una buona idea anche quando si esegue l'autenticazione con AD?

EDIT: Seconda parte della domanda generato a thread separato: Best practices for server-side handling of JWT tokens

Inoltre, ho una preoccupazione più generale, riguardo a ciò che la pratica migliore è per la verifica in realtà gettoni. Supponiamo che il "segreto" usato per la generazione di JWT sia compromesso (nel mio scenario molte persone potrebbero avere accesso al codice sorgente del sistema, ma non al sistema stesso). Ho ragione nel ritenere che un utente malintenzionato potrebbe quindi, con solo queste informazioni, generare un token per conto di un determinato utente e senza mai autenticare con AD utilizzare quel token nelle mie richieste API? Generalmente un token viene generato utilizzando jwt.sign(payload, secretOrPrivateKey, options). In alternativa, supponiamo che un utente malintenzionato possa impossessarsi di un token effettivo (prima che sia scaduto). A me sembra invece di dover conoscere il nome utente e la password di un utente, ora la sicurezza è ridotta a conoscere il nome utente e il segreto JWT. È una preoccupazione valida e cosa dovrei fare per impedirlo?

La mia migliore speranza è quella di utilizzare una sessione lato server per archiviare le informazioni sull'utente corrente dopo l'accesso, in modo che anche se un token viene generato e utilizzato maliziosamente quando accede agli end-end backend, fallirebbe se l'utente non avesse effettivamente passato attraverso il percorso di accesso, autenticato con AD e memorizzato alcune informazioni nella sessione come risultato di questo.

Ho anche considerato in realtà l'autenticazione con AD in ogni API endpoint, ma che richiederebbero l'AD nome utente/password da inviare a ogni richiesta, che a sua volta richiederebbe che le informazioni sensibili avrebbe dovuto essere immagazzinate nella cliente di sessionstorage o localstorage, che è molto probabilmente una cattiva idea.

Quindi, domande:

1) E 'ragionevole per combinare l'autorizzazione AD con JWT come portatore di token o che cosa è il modo migliore per costruire un sicuro backend + frontend utilizzando AD per l'autenticazione?

2) Se JWT è una buona idea, qual è la procedura migliore per proteggere gli endpoint utilizzando JWT? È ragionevole usare una sessione lato server?

È interessante notare che ho trovato un sacco di esempi su come implementare al meglio l'autenticazione basata su token (in generale, o con NodeJS in particolare), ma molti di essi sembrano imperfetti in un modo o nell'altro.

+0

Puoi chiarire o espandere la domanda 2)? Intendi proteggere le comunicazioni tra i servizi server e back-end o un mezzo per comunicazioni client-server sicure senza avere il pass di un JWT in ogni richiesta? – frasertweedale

+0

Né immagino, intendo le migliori pratiche generali su come un token JWT deve essere validato in modo sicuro e su come i segreti dei server devono essere gestiti. Consentitemi di generare questo in una domanda a parte: http://stackoverflow.com/questions/30523238/best-practices-for-server-side-handling-of-jwt-tokens – JHH

+0

Grazie per il chiarimento. Aggiornerò la mia risposta – frasertweedale

risposta

2

1) È ragionevole combinare autorizzazione AD con JWT come portatore di token o che cosa è il modo migliore per costruire un sicuro backend + frontend utilizzando AD per l'autenticazione?

E 'ragionevole, ma se si sta già utilizzando Kerberos e AD per autenticare inizialmente l'utente, si potrebbe considerare l'utilizzo di s4u2proxydelega vincolata che permette il servizio di presentare ticket di servizio dell'utente al KDC e acquisire (soggetto a controlli di autorizzazione) un biglietto per un servizio di back-end (e ripetere per quanti servizi sono necessari).

Se si dispone di un sacco di servizi di back-end che hanno bisogno di essere contattato, un unico JWT che porta tutte le domande di autorizzazione necessarie per tutte i servizi per far rispettare criteri di autorizzazione può essere una soluzione migliore.

2) Se JWT è una buona idea, qual è la procedura migliore per proteggere gli endpoint utilizzando JWT? È ragionevole usare una sessione lato server? si applicano

procedure di protezione chiave generale:

  • Mai chiavi negozio in chiaro nella memoria non volatile, ovunque.
  • Idealmente non archiviare chiavi crittografate nella memoria collegata sul server dove, se il server è compromesso, sarebbero soggetti a un attacco offline. Rendili disponibili all'host solo all'avvio del server.
  • Verificare che il materiale chiave risieda nella memoria protetta in modo che non possa essere scambiato su disco (e/o utilizzare lo scambio crittografato).
  • Utilizzare algoritmi a chiave pubblica in modo che non sia necessaria alcuna chiave segreta su più host.
  • Considerare l'utilizzo di hardware security module (HSM).
+0

Grazie per l'informazione. Ho solo un singolo servizio API di back-end che deve essere protetto con un meccanismo basato su token derivato dall'autenticazione AD/Kerberos. Probabilmente userò JWT quindi. – JHH

Problemi correlati