standard - Secure Web Services: REST su HTTPS vs SOAP+WS-Security. Che è migliore?




wsdl 2.0 wiki (8)

Non sono un esperto di sicurezza in alcun modo, ma mi piace creare servizi web in stile REST.

Nella creazione di un nuovo servizio che deve avere i dati che trasmette sicuri. Abbiamo inserito un dibattito su quale approccio è più sicuro: REST con HTTPS o SOAP WS con WS-Security.

Ho l'impressione che potremmo utilizzare HTTPS per tutte le chiamate al servizio web e questo approccio sarebbe sicuro. Il modo in cui lo guardo è, "se HTTPS è abbastanza buono per i siti Web bancari e finanziari, è abbastanza buono per me". Ancora una volta, non sono esperto in questo spazio, ma penserei che queste persone abbiano riflettuto molto su questo problema e si sentano a proprio agio con HTTPS.

Un collega non è d'accordo e afferma che SOAP e WS-Security sono l'unico modo per andare.

Il web sembra su tutta la linea su questo.

Forse la comunità qui potrebbe valutare i pro ei contro di ciascuno? Grazie!


Come dici tu, REST è abbastanza buono per le banche, quindi dovrebbe essere abbastanza buono per te.

Ci sono due aspetti principali della sicurezza: 1) crittografia e 2) identità.

La trasmissione in SSL / HTTPS fornisce la crittografia via cavo. Ma dovrai anche assicurarti che entrambi i server possano confermare di sapere con chi stanno parlando. Questo può avvenire tramite certificati client SSL, segreti delle condivisioni, ecc.

Sono sicuro che si potrebbe affermare che SOAP è "più sicuro" ma probabilmente non in modo significativo. L'analogia del motociclista nudo è carina ma se accurata implicherebbe che l'intera rete non sia sicura.


Dal punto di vista tecnico, non è corretto, perché la comunicazione del metodo SOAP non è sicura e il metodo REST non dice nulla sull'autenticazione degli utenti legittimi.

HTTPS impedisce agli aggressori di eavesdropping la comunicazione tra due sistemi. Verifica inoltre che il sistema host (server) sia effettivamente il sistema host a cui l'utente intende accedere.

WS-Security impedisce alle applicazioni non autorizzate (utenti) di accedere al sistema.

Se un sistema RESTful ha un modo di autenticare gli utenti e un'applicazione SOAP con WS-Security utilizza HTTPS, allora entrambi sono sicuri. È solo un modo diverso di presentare e accedere ai dati.


La risposta dipende in realtà dalle tue esigenze specifiche.

Ad esempio, è necessario proteggere i propri messaggi Web o la riservatezza non è richiesta e tutto ciò di cui si ha bisogno è autenticare gli utenti finali e garantire l'integrità dei messaggi? Se questo è il caso - e spesso è con i servizi web - HTTPS è probabilmente il martello sbagliato.

Tuttavia, dalla mia esperienza, non trascurare la complessità del sistema che stai costruendo. Non solo HTTPS è più facile da implementare correttamente, ma un'applicazione che si basa sulla sicurezza del livello di trasporto è più facile da eseguire il debug (su semplice HTTP).

In bocca al lupo.


La sicurezza REST dipende dal trasporto mentre la sicurezza SOAP non lo è.

REST eredita le misure di sicurezza dal trasporto sottostante mentre SOAP ne definisce le proprie tramite WS-Security.

Quando parliamo di REST, su HTTP, tutte le misure di sicurezza applicate a HTTP vengono ereditate e questo è noto come sicurezza a livello di trasporto.

Sicurezza del livello di trasporto, protegge il tuo messaggio solo mentre è sul filo: non appena il filo lascia il filo, il messaggio non è più protetto.

Ma con WS-Security, la sua sicurezza a livello di messaggio - anche se il messaggio lascia il canale di trasporto, sarà comunque protetto. Inoltre, con la sicurezza a livello di messaggio è possibile crittografare parzialmente il messaggio [non l'intero messaggio, ma solo le parti che si desidera], ma con la sicurezza a livello di trasporto non è possibile farlo.

WS-Security ha misure per l'autenticazione, l'integrità, la riservatezza e il non ripudio mentre SSL non supporta il ripudio [con OAuth a 2 gambe].

In termini di prestazioni, SSL è molto più veloce di WS-Security.

Grazie...


Non ho ancora il rappresentante necessario per aggiungere un commento o avrei solo aggiunto questo alla risposta di Bell. Penso che Bell abbia fatto un ottimo lavoro nel riassumere i pro ei contro di alto livello dei due approcci. Solo alcuni altri fattori che potresti voler considerare:

1) Le richieste tra i tuoi clienti e il tuo servizio devono passare attraverso intermediari che richiedono l'accesso al carico utile? In tal caso, WS-Security potrebbe essere più adatto.

2) In realtà è possibile utilizzare SSL per fornire al server la sicurezza dell'identità dei client utilizzando una funzionalità chiamata autenticazione reciproca. Tuttavia, questo non ha molto senso al di fuori di alcuni scenari molto specializzati a causa della complessità della sua configurazione. Quindi Bell ha ragione che WS-Sec è molto più adatto qui.

3) SSL in generale può essere un po 'difficile da configurare e mantenere (anche nella configurazione più semplice) a causa in gran parte dei problemi di gestione dei certificati. Avere qualcuno che sa come farlo per la tua piattaforma sarà un grande vantaggio.

4) Se potrebbe essere necessario fare una qualche forma di mappatura delle credenziali o di federazione delle identità, WS-Sec potrebbe valerne la pena. Non è che non puoi farlo con REST, hai solo meno strutture per aiutarti.

5) Portare tutti gli strumenti WS-Security nei posti giusti sul lato client delle cose può essere più doloroso di quanto si possa pensare.

Alla fine, però, dipende davvero da molte cose che probabilmente non sapremo. Per la maggior parte delle situazioni, direi che entrambi gli approcci saranno "abbastanza sicuri" e quindi non dovrebbero essere il principale fattore decisivo.


REST su HTTPS Dovrebbe essere un metodo sicuro finché il provider API implementa l'autorizzazione di un server. In un caso di applicazione web, anche quello che facciamo è accedere a un'applicazione Web tramite HTTPS e qualche autenticazione / autorizzazione, tradizionalmente le applicazioni web non hanno problemi di sicurezza, quindi l'API restful risolve anche i problemi di sicurezza senza problemi!


Vedi l'articolo wiki :

Nelle situazioni point-to-point, la riservatezza e l'integrità dei dati possono anche essere applicate ai servizi Web tramite l'utilizzo di Transport Layer Security (TLS), ad esempio inviando messaggi tramite https.

WS-Security tuttavia affronta il problema più ampio di mantenere l'integrità e la riservatezza dei messaggi fino a quando non è stato inviato un messaggio dal nodo di origine, fornendo la cosiddetta sicurezza end-to-end.

Questo è:

  • HTTPS è un meccanismo di sicurezza del livello di trasporto (punto-punto)
  • WS-Security è un meccanismo di sicurezza a livello di applicazione (end-to-end).

Brace yourself, here there's another coming :-)

Oggi ho dovuto spiegare alla mia ragazza la differenza tra la potenza espressiva di WS-Security e HTTPS. Lei è una scienziata informatico, quindi anche se non conosce tutto il mumbo jumbo XML capisce (forse meglio di me) cosa significa crittografia o firma. Tuttavia volevo un'immagine forte, che potesse farle capire davvero a cosa servono le cose, piuttosto che come sono implementate (che è venuto un po 'più tardi, non l'ha sfuggita :-)).

Quindi va così. Supponiamo che tu sia nudo e che tu debba guidare la tua motocicletta verso una certa destinazione. Nel caso (A) si passa attraverso un tunnel trasparente: la tua unica speranza di non essere arrestati per comportamento osceno è che nessuno sta guardando. Non è esattamente la strategia più sicura con cui puoi uscire ... (nota il sudore che cade dalla fronte del ragazzo :-)). Questo è equivalente a un POST in chiaro, e quando dico "equivalente" lo intendo. Nel caso (B), ti trovi in ​​una situazione migliore. Il tunnel è opaco, quindi finché viaggi in esso il tuo registro pubblico è sicuro. Tuttavia, questa non è ancora la situazione migliore. Devi ancora uscire di casa e raggiungere l'entrata del tunnel, e una volta fuori dal tunnel probabilmente dovrai scendere e camminare da qualche parte ... e questo vale per HTTPS. È vero, il tuo messaggio è al sicuro mentre attraversa il baratro più grande: ma una volta che l'hai consegnato dall'altra parte, non sai davvero quante tappe dovrà attraversare prima di raggiungere il punto reale in cui i dati saranno elaborati. E naturalmente tutte quelle fasi potrebbero usare qualcosa di diverso da HTTP: un MSMQ classico che bufferizza le richieste che non possono essere servite immediatamente, per esempio. Cosa succede se qualcuno si annida i dati mentre si trovano in quel limbo di pre-elaborazione? Hm. (leggi questo "hm" come quello pronunciato da Morfeo alla fine della frase "pensi che sia l'aria che stai respirando?"). La soluzione completa (c) in questa metafora è dolorosamente banale: procurati dei vestiti dannatamente su te stesso, e specialmente sul casco mentre sei in motocicletta !!! Quindi puoi tranquillamente andare in giro senza dover fare affidamento sull'opacità degli ambienti. Si spera che la metafora sia chiara: gli abiti vengono con te indipendentemente dalla media o dall'infrastruttura circostante, come fa la sicurezza del livello di messaggistica. Inoltre, puoi decidere di coprire una parte ma rivelarne un'altra (e puoi farlo su base personale: la sicurezza dell'aeroporto può togliere la giacca e le scarpe, mentre il medico può avere un livello di accesso più alto), ma ricorda che le camicie a maniche corte sono cattive prove anche se sei orgoglioso dei tuoi bicipiti :-) (meglio un polo o una t-shirt).

Sono felice di dire che ha capito il punto! Devo dire che la metafora dell'abbigliamento è molto potente: sono stato tentato di usarlo per introdurre il concetto di politica (i club discografici non ti lasceranno alle scarpe sportive, non puoi andare a prelevare denaro in una banca in mutande , mentre questo è perfettamente accettabile mentre ti rilassi su un surf, e così via) ma pensavo che per un pomeriggio fosse abbastanza ;-)

Architettura - WS, Wild Ideas

Per gentile concessione: http://blogs.msdn.com/b/vbertocci/archive/2005/04/25/end-to-end-security-or-why-you-shouldn-t-drive-your-motorcycle-naked.aspx





soap