Come proteggere i servizi Web quando l'autenticazione viene eseguita sul lato client (frontend)

0

Ho un'applicazione web la cui struttura è come -

  • webapi: servizi web di django [NON REST] nessuna sicurezza implementata
  • frontend: Angular2. autenticazione implementata tramite SAML
  • Database: Mongodb

Puoi suggerire il modo migliore per proteggere webapi, dato che attualmente chiunque può accedere ai servizi web che hanno server [api] url

Sarà di grande aiuto se suggerisci il flusso di autenticazione e autorizzazione perché sono totalmente bloccato. Grazie in anticipo.

    
posta sachin27 07.12.2017 - 08:22
fonte

2 risposte

0

Descriverò due modi in cui puoi farlo:

OAuth

Ti consigliamo di utilizzare OAuth per l'API Web. Non è necessario sostituire l'autenticazione SAML se non si desidera (anche se sarebbe più coerente se si è utilizzato OIDC per l'autorizzazione dell'applicazione).

Fondamentalmente, avresti autenticato la tua app di primavera tramite SAML, quindi, quando avevi interrogato l'API web, nella fase di richiesta di autorizzazione del flusso di lavoro OAuth, avresti implementato il server di autorizzazione sullo stesso server della tua app di primavera in modo da può utilizzare il contesto di sessione come autenticazione per la richiesta di autorizzazione.

Dovresti dare un'occhiata a qui per ottenere un'introduzione a OAuth. OAuth è stato progettato (in parte) per risolvere esattamente questo problema.

Mi rendo conto che questo è breve sui dettagli di OAuth ma ci sono molti buoni esempi / tutorial su come fare questo. Devi solo riconoscere che, nel flusso del protocollo, la tua app di primavera sarebbe servita al ruolo di Authorization Server e fornirà implicitamente Authorization Grants per il servizio API Web per le richieste di autorizzazione provenienti da client autenticati SAML.

La tua app è ciò a cui OAuth si riferisce come app singola (nessun client basato su sever). Il flusso per le app a pagina singola è descritto qui . Essenzialmente, la tua app di primavera implementerà un server di autorizzazione OAuth, la tua app angolare (nel browser) richiederà un codice di autorizzazione dal server di autorizzazione. Se si desidera che l'utente approvi l'accesso, verrà creata una pagina di approvazione che descrive le azioni API che stanno approvando. Se vuoi che questo sia trasparente, devi semplicemente restituire il codice di autorizzazione. Una volta che l'app ha un codice di autorizzazione, scambia immediatamente il codice con il server di autorizzazione per un token di accesso API.

La tua app Angular richiederebbe quindi l'API utilizzando il token di accesso OAuth. L'API riceve il token di accesso, convalida che è "buono", quindi consente (o nega) l'accesso. Si convalida che il token è "buono" tramite un database condiviso con il server di autorizzazione (ovvero quando il server di autenticazione crea un token, lo memorizza nel database per la convalida successiva da parte del server API) o decodificando un token self -encoded (in pratica il server di autenticazione e il server api condividono una chiave di codifica e il token è una stringa codificata che ha tutte le informazioni necessarie all'API per concedere / negare l'accesso).

roll-your-own

Se OAuth è un po 'troppo scoraggiante (anche se è discutibilmente il modo giusto per andare qui ...) ho usato anche un semplice schema di token di autorizzazione cresciuto in casa.

In questo caso si progetta la propria API Web per richiedere un token di accesso (fornito dai client in un'intestazione, in una stringa o in un payload della query). Quando si autentica l'app del client, il server Spring genera un token e lo rimanda (in modo sicuro tramite tls / ssl) al client per l'uso con django web api. Il token è crittografato con una chiave condivisa (tra l'app di primavera e l'app django) e ha una struttura che l'app django può contenere (di solito includo un timestamp per limitare la riproduzione, nome utente per l'autorizzazione locale, a volte le informazioni di autorizzazione personalizzate che l'API può usare invece di prendere decisioni di autenticazione locale). Ti raccomanderei anche di salare il messaggio per rendere più difficile l'attacco in chiaro del token. Un'altra opzione per limitare la riproduzione è rendere i token unici e richiedere un recupero di token ogni volta che si effettua una query. Infine, se si utilizza un timestamp (i secondi interi epoch sono convenienti ...) è necessario assicurarsi che i server spring e django siano (almeno in qualche modo) sincronizzati nel tempo.

    
risposta data 07.12.2017 - 22:22
fonte
1

Che webapi senza autenticazione è un rischio per la sicurezza. Poiché stai già utilizzando SAML, accedi alla pagina di Wikipedia come punto di partenza. Sul grafico in basso il tuo webapi è il fornitore di servizi

    
risposta data 07.12.2017 - 11:21
fonte

Leggi altre domande sui tag