Servizio web RESTful: come autenticare le richieste da altri servizi?

Sto progettando un servizio Web RESTful a cui gli utenti devono accedere, ma anche altri servizi Web e applicazioni. Tutte le richieste in arrivo devono essere autenticate. Tutte le comunicazioni avvengono tramite HTTPS. L'autenticazione dell'utente funzionerà in base a un token di autenticazione, acquisito tramite POST del nome utente e della password (su una connessione SSL) a una risorsa / session fornita dal servizio.

Nel caso dei client del servizio Web, non vi è alcun utente finale dietro il servizio client. Le richieste vengono avviate da attività pianificate, eventi o altre operazioni del computer. L'elenco dei servizi di connessione è noto in anticipo (ovviamente, immagino). Come devo autenticare queste richieste provenienti da altri servizi (web)? Voglio che il processo di autenticazione sia il più semplice possibile da implementare per questi servizi, ma non a scapito della sicurezza. Quali sarebbero lo standard e le migliori pratiche per uno scenario come questo?

Opzioni a cui posso pensare (o che mi sono state suggerite):

1. Chiedi ai servizi client di ricorrere a un nome utente e una password "falsi" e di autenticarli allo stesso modo degli utenti. Non mi piace questa opzione, semplicemente non mi sembra giusta.

2. Assegna un ID applicazione permanente per il servizio client, possibilmente anche una chiave dell'applicazione. Per quanto ho capito, è come avere nome utente + password. Con questo ID e questa chiave, posso autenticare ogni richiesta o creare un token di autenticazione per autenticare ulteriori richieste. Ad ogni modo, questa opzione non mi piace, perché chiunque possa ottenere una copia dell'ID e della chiave dell'applicazione può impersonare il client.

3. Potrei aggiungere un controllo dell'indirizzo IP all'opzione precedente. Ciò renderebbe più difficile eseguire richieste false.

4. Certificati client. Imposta la mia autorità di certificazione, crea il certificato radice e crea certificati client per i servizi client. Mi vengono in mente un paio di problemi: a) come posso ancora consentire agli utenti di autenticarsi senza certificati eb) quanto è complicato questo scenario da implementare dal punto di vista del servizio client?

5. Qualcos'altro: ci devono essere altre soluzioni là fuori?

Il mio servizio sarebbe in esecuzione su Java, ma ho deliberatamente tralasciato le informazioni su quale framework specifico sarebbe stato costruito, perché sono più interessato ai principi di base e non tanto ai dettagli di implementazione - presumo che la soluzione migliore per questo sarà essere possibile implementare indipendentemente dal framework sottostante. Tuttavia, sono un po 'inesperto con questo argomento, quindi saranno molto apprezzati anche suggerimenti ed esempi concreti sull'attuale implementazione (come utili librerie di terze parti, articoli, ecc.).

Qualsiasi soluzione a questo problema si riduce a un segreto condiviso. Inoltre non mi piace l'opzione nome utente e password hardcoded, ma ha il vantaggio di essere abbastanza semplice. Anche il certificato client è buono, ma è davvero molto diverso? C'è un certificato sul server e uno sul client. Il vantaggio principale è che è più difficile usare la forza bruta. Si spera che tu abbia altre protezioni per proteggerti da questo.

Non credo che il tuo punto A per la soluzione del certificato client sia difficile da risolvere. Devi solo usare un ramo. if (client side certificat) { check it } else { http basic auth }Non sono un esperto di Java e non ho mai lavorato con esso per creare certificati lato client. Tuttavia, un rapido Google ci porta a questo tutorial che sembra proprio il tuo vicolo.

Nonostante tutta questa discussione su "cosa è meglio", lasciatemi sottolineare che esiste un'altra filosofia che dice: "meno codice, meno intelligenza è meglio". (Personalmente sostengo questa filosofia). La soluzione del certificato client suona come un sacco di codice.

So che hai espresso domande su OAuth, ma la proposta OAuth2 include una soluzione al tuo problema chiamata " bearer token " che deve essere utilizzata insieme a SSL. Penso, per semplicità, sceglierei l'utente / pass hard-coded (uno per app in modo che possano essere revocati individualmente) o i token di portatore molto simili.

Dopo aver letto la tua domanda, direi, genera un token speciale per fare richiesta richiesta. Questo token vivrà in un tempo specifico (diciamo in un giorno).

Ecco un esempio da per generare il token di autenticazione:

(day * 10) + (month * 100) + (year (last 2 digits) * 1000)

ad esempio: 3 giugno 2011

(3 * 10) + (6 * 100) + (11 * 1000) = 
30 + 600 + 11000 = 11630

quindi concatenare con la password dell'utente, ad esempio "my4wesomeP4ssword!"

11630my4wesomeP4ssword!

Quindi fai MD5 di quella stringa:

05a9d022d621b64096160683f3afe804

Quando chiami una richiesta, usa sempre questo token,

https://mywebservice.com/?token=05a9d022d621b64096160683f3afe804&op=getdata

Questo token è sempre unico ogni giorno, quindi immagino che questo tipo di protezione sia più che sufficiente per proteggere sempre il tuo servizio.

La speranza aiuta

:)

Esistono diversi approcci che puoi adottare.

1. I puristi RESTful vorranno che tu utilizzi l'autenticazione BASIC e invii le credenziali a ogni richiesta. La loro logica è che nessuno memorizza nessuno stato.

2. Il servizio client potrebbe memorizzare un cookie, che mantiene un ID di sessione. Personalmente non lo trovo offensivo come alcuni dei puristi da cui ho sentito parlare: può essere costoso autenticarsi più e più volte. Tuttavia, sembra che questa idea non ti piaccia troppo.

3. Dalla tua descrizione, sembra davvero che potresti essere interessato a OAuth2 La mia esperienza finora, da quello che ho visto, è che è un po 'confuso e un po' sanguinante. Ci sono implementazioni là fuori, ma sono poche e lontane tra loro. In Java, ho capito che è stato integrato nei moduli di sicurezza di Spring3 . (Il loro tutorial è scritto bene.) Stavo aspettando di vedere se ci sarà un'estensione in Restlet , ma finora, sebbene sia stato proposto e potrebbe essere nell'incubatore, non è stato ancora completamente incorporato.

Credo che l'approccio:

1. Prima richiesta, il client invia ID / passcode
2. Scambia ID / passaggio per token univoco
3. Convalida il token su ogni richiesta successiva fino alla scadenza

è piuttosto standard, indipendentemente da come si implementa e da altri dettagli tecnici specifici.

Se vuoi davvero spingere la busta, forse potresti considerare la chiave https del client in uno stato temporaneamente non valido fino a quando le credenziali non vengono convalidate, limitare le informazioni se non lo sono mai e concedere l'accesso quando vengono convalidate, in base alla scadenza.

Spero che questo ti aiuti

Per quanto riguarda l'approccio del certificato client, non sarebbe molto difficile da implementare pur consentendo agli utenti senza certificati client di entrare.

Se in effetti creassi la tua Autorità di certificazione autofirmata e avessi emesso certificati client a ciascun servizio client, avresti un modo semplice per autenticare quei servizi.

A seconda del server web in uso, dovrebbe esserci un metodo per specificare l'autenticazione del client che accetterà un certificato del client, ma non ne richiede uno. Ad esempio, in Tomcat, quando si specifica il connettore https, è possibile impostare "clientAuth = want" invece di "true" o "false". Dovresti quindi assicurarti di aggiungere il tuo certificato CA autofirmato al tuo truststore (per impostazione predefinita il file cacerts nel JRE che stai utilizzando, a meno che tu non abbia specificato un altro file nella configurazione del tuo server web), in modo che gli unici certificati affidabili sarebbero quelli emessi da la tua CA autofirmata.

Sul lato server, consenti l'accesso ai servizi che desideri proteggere solo se sei in grado di recuperare un certificato client dalla richiesta (non nullo) e supera i controlli DN se preferisci una sicurezza aggiuntiva. Per gli utenti senza certificati client, potrebbero comunque accedere ai tuoi servizi, ma semplicemente non avranno certificati presenti nella richiesta.

Secondo me questo è il modo più "sicuro", ma sicuramente ha la sua curva di apprendimento e il suo overhead, quindi potrebbe non essere necessariamente la soluzione migliore per le tue esigenze.

5. Qualcos'altro: devono esserci altre soluzioni là fuori?

Hai ragione, c'è! E si chiama JWT (JSON Web Tokens).

JSON Web Token (JWT) è uno standard aperto (RFC 7519) che definisce un modo compatto e autonomo per trasmettere in modo sicuro le informazioni tra le parti come oggetto JSON. Queste informazioni possono essere verificate e attendibili perché sono firmate digitalmente. I JWT possono essere firmati utilizzando un segreto (con l'algoritmo HMAC) o una coppia di chiavi pubblica / privata utilizzando RSA.

Consiglio vivamente di esaminare i JWT. Sono una soluzione molto più semplice al problema rispetto a soluzioni alternative.

https://jwt.io/introduction/

È possibile creare sessioni sul server e condividere sessionIdtra client e server con ogni chiamata REST.

1. Prima richiesta REST autenticazione: /authenticate. Restituisce la risposta (secondo il formato del cliente) con sessionId: ABCDXXXXXXXXXXXXXX;

2. Conservare questo sessionIdin Mapcon la sessione attuale. Map.put(sessionid, session)o utilizzare SessionListenerper creare e distruggere chiavi per te;

   public void sessionCreated(HttpSessionEvent arg0) {
     // add session to a static Map 
   }
   
   public void sessionDestroyed(HttpSessionEvent arg0) {
     // Remove session from static map
   }
   

3. Ottieni sessionid con ogni chiamata REST, come URL?jsessionid=ABCDXXXXXXXXXXXXXX(o in altro modo);

4. Recupera HttpSessiondalla mappa utilizzando sessionId;
5. Convalida la richiesta per quella sessione se la sessione è attiva;
6. Invia risposta o messaggio di errore.

Vorrei che un'applicazione reindirizzasse un utente al tuo sito con un parametro id applicazione, una volta che l'utente approva la richiesta, genera un token univoco che viene utilizzato dall'altra app per l'autenticazione. In questo modo le altre applicazioni non gestiscono le credenziali utente e altre applicazioni possono essere aggiunte, rimosse e gestite dagli utenti. Foursquare e pochi altri siti si autenticano in questo modo ed è molto facile da implementare come l'altra applicazione.

Oltre all'autenticazione, ti suggerisco di pensare al quadro generale. Considera l'idea di creare il tuo servizio RESTful di backend senza alcuna autenticazione; quindi inserire un servizio di livello intermedio richiesto per l'autenticazione molto semplice tra l'utente finale e il servizio di backend.