Protezione di una API REST a livello di messaggio

A meno che non mi sia sfuggito qualcosa, la tua soluzione sembra terribilmente simile a un servizio token di sicurezza. Per un STS, la chiave è avere una parte affidabile per identificare la parte che avvia la parte relying. Nel tuo caso il trust broker e il relying party sembrano essere la stessa entità.

Se il tuo obiettivo è far propagare la fiducia alla destinazione finale, usa semplicemente SSL attraverso il proxy e usa un certificato client per identificare il punto finale. Supponendo che tu voglia che HTTP passi attraverso il tuo proxy per ispezionare il traffico, implementa un STS standard.

Come ha detto Xander, REST è ottimo per le chiamate di servizio leggere, ma nel momento in cui vuoi fare sicurezza dovresti usare SOAP, in particolare l'estensione WS-Security. Non è così difficile, specialmente se controlli entrambe le estremità come fai tu. Vedi questo domanda di overflow dello stack per come farlo in Java su Android.

Se vai avanti con la soluzione a casa, vale la pena notare che gli ultimi tre proiettili nella tua Autenticazione sembrano essere il tuo punto debole.

Non posso dire di averli esaminati nei dettagli, ma potresti essere interessato ai tentativi esistenti di implementare Message-Level Security a livello HTTP. Ad esempio:

• SEA: un'architettura di estensione della sicurezza per HTTP / 1.x

• HTTPSec : il progetto era in httpsec.org ma è ora scomparso. È ancora disponibile tramite l'archivio Web (il documento è disponibile sotto il GNU FDL per quanto ne so io. Secarta, che ha sviluppato questa specifica, ha anche fornito un'implementazione Java non libera.

Entrambi i progetti sembrano inattivi. Possono anche mancare il controllo esperto che altri protocolli di sicurezza solitamente hanno o dovrebbero avere. Questo non vuol dire che ci sia qualcosa di sbagliato in loro. Sospetto che la mancanza di successo di HTTPsec sia dovuta piuttosto al suo arrivo durante le "guerre SOAP vs REST" (aggiungendo un po 'di complessità sul lato REST) e il fatto che avesse solo un'implementazione (in Java) con un non- licenza gratuita.

Indagare se la crittografia e la firma delle entità dei messaggi con strumenti esistenti come OpenPGP potrebbero essere di interesse.

REST è una parola che ha un significato diverso per varie persone. A volte, significa solo payload su HTTP, senza i molteplici livelli di SOAP. Se tali servizi effettivamente seguono i principi HATEOS è un'altra questione.

La mia opinione personale su questo è che l'apolidia di REST dovrebbe essere applicata alle caratteristiche principali dell'applicazione, non necessariamente ai suoi aspetti di sicurezza. Ovviamente è molto difficile (se non impossibile) impedire attacchi di riproduzione senza mantenere una sorta di stato sul lato del destinatario.

Detto questo, non sono sicuro dalle tue domande che sei interessato alla pura sicurezza a livello di messaggio. Piuttosto, sembra che tu sia interessato principalmente al tunneling di un equivalente di SSL / TLS tramite HTTP, perché non sei in grado di eseguire una connessione TCP diretta dal client al back-end. Poiché stai anche utilizzando SSL / TLS, questo suggerisce che il motivo principale di tutto questo è che non ti fidi del bilanciamento del carico. Cercare di scrivere il proprio protocollo è generalmente difficile, e spesso una cattiva idea. Le raccomandazioni riguardanti la crittografia e gli algoritmi MAC dipendono dai dettagli. (In confronto, ci sono voluti alcuni istanti per identificare e affrontare alcuni problemi con TLS, anche se si tratta di un protocollo aperto con specifiche dettagliate, studiato da un numero di esperti.)