Autenticazione tra servizi Web all'interno dello stesso progetto

Se il tuo sistema è relativamente piccolo e non sei troppo preoccupato per gli attacchi man-in-the-middle, allora una chiave precondivisa è il modo più semplice per procedere. Pensala come una password che un server usa per riconoscerne un'altra. Idealmente ogni server ha una propria password che viene utilizzata per identificarsi con gli altri. Se necessario, puoi evitare di rivelare la password e allo stesso tempo dimostrarne la conoscenza utilizzando un challenge-response meccanismo di hashing.

Se il tuo sistema è di grandi dimensioni o l'aggiunta e la rimozione di nodi è abbastanza frequente da rendere difficile la manutenzione delle chiavi pre-condivise, ti consigliamo di creare la tua PKI. Questo è abbastanza semplice da fare con i certificati SSL: basta generare un certificato di firma centrale e contrassegnarlo (e da solo) come attendibile su tutti i server e rilasciare a ogni server / servizio il proprio certificato che utilizza per identificarsi con gli altri. Utilizza il campo oggetto del certificato per legare il certificato al server / servizio e, ovviamente, firmalo con il tuo certificato di firma. SSL fornisce l'autenticazione reciproca di client e server per una singola connessione, quindi è possibile utilizzare componenti completamente disponibili per questo. Se necessario, puoi includere brevi tempi di scadenza e / o usare la revoca per aumentare la sicurezza se sei preoccupato che le chiavi cadano nelle mani sbagliate.

Stai facendo due domande separate qui.

Accesso programmatico. La prima domanda è: per i servizi Web che dovrebbero essere esposti solo ad altri codici interni, come devono essere autenticati i client programmatici? La mia risposta: raccomando di usare SSL con i certificati client.

Ecco come farlo, più in dettaglio. Il cliente deve contattare il servizio tramite un URL https. Ogni client deve essere fornito con il proprio certificato client SSL. Il servizio dovrebbe verificare che il certificato del cliente si trovi su un elenco di clienti autorizzati, oppure controllare che il certificato cliente sia firmato dalla CA interna (a tua scelta).

Inoltre, per una maggiore sicurezza, potresti prendere in considerazione l'esecuzione di tali servizi Web interni su un host separato protetto dal mondo esterno, in modo che nessuno su Internet esterno possa aprire una connessione a tali servizi Web interni.

Accesso umano. La seconda domanda è: per i servizi Web che dovrebbero essere esposti solo agli amministratori di sistema interni, come dovrebbe essere controllato l'accesso? La mia risposta: ci sono diversi approcci.

La risposta più semplice e probabilmente la più pragmatica è impostare un account separato per ciascuno dei tuoi amministratori e utilizzare l'autenticazione basata su password standard per limitare l'accesso a tali account. Genera una password lunga e sicura per ciascun account amministratore e comunica all'amministratore di non condividere la password. Configurare il servizio Web per utilizzare SSL in tutto il sito (accessibile solo tramite https, non via http), per impedire agli aggressori di annusare la password di un amministratore se si connettono tramite una connessione WiFi aperta. In questo approccio, i servizi Web sono ancora in esecuzione su un host connesso a Internet, rivolto verso l'esterno, ma nessuno deve essere in grado di accedere a loro.

Un approccio più sicuro consiste nel mettere tali servizi Web nella rete interna e non collocarli su un host esterno. Firewall via Internet esterno. Se i tuoi amministratori vogliono accedere mentre stanno lavorando in remoto, possono collegarsi alla rete interna tramite VPN. Dovrai comunque creare un account per ogni amministratore del servizio web e generare password complesse e lunghe per gli amministratori.

Per installazioni ad alta sicurezza, esistono altri modi per fornire una sicurezza ancora più strong. Questi meccanismi probabilmente non sono necessari per il servizio web interno medio, ma se ti trovi in un'area particolarmente sensibile alla sicurezza, faccelo sapere e possiamo fornirti ulteriori controlli.

La tua domanda non è molto chiara. Suona come se fosse interessato all'autenticazione intra service, che non è quello che presumo tu stia cercando di risolvere.

What we need to prevent here is, basically, random people submitting queries/posts to this web services that are only meant to be used by the other ones.

Quindi, se l'obiettivo è di consentire solo agli utenti che puoi autenticare, indirizzerei il tuo provider di autenticazione delle rotaie al sistema di "autenticazione globale". Presumo che abbia un'interfaccia LDAP quindi dovrebbe essere piuttosto semplice configurarlo.

La tua autenticazione servirà anche come autorizzazione poiché il tuo obiettivo era solo quello di consentire agli utenti che puoi autenticare.

Con un token di chiave casuale per utente, lato server, che è sconosciuto all'utente, ma solo ai servizi web. In questo modo, hai ottenuto ogni esecuzione in un contesto specifico, come se avessi assegnato un nome utente ad esso. Questo può essere passato tramite richiesta HTTP XML, o nell'intestazione del cookie, o nell'URL, dipende dai tuoi requisiti.

Semplicemente ogni sessione richiede una pre-autenticazione di qualche tipo e usa i token attraverso i servizi, quindi non devi effettuare nuovamente il login.

Funziona come utente-server, allo stesso modo funziona server-server, come il server deve accedere al sito Web, e quindi può sfogliare le pagine, in questo caso, i servizi Web.

Anche quando l'utente esegue il login, può ottenere anche questo token, in modo da poter collegare l'utente front-end con la sessione back-end.