2009-09-16 5 views
22

Mi piacerebbe creare un'architettura di servizi Web che possa essere chiamata da varie piattaforme come dispositivi mobili, applicazioni winforms, iphone, blackberry, come si chiama. Quindi andare con qualcosa come WCF e wsHttp binding probabilmente uccide questo e mi piacerebbe dover effettuare il downgrade a un binding Http di base per la compatibilità.Il modo migliore per creare un sistema TOKEN per autenticare le chiamate ai servizi Web?

Detto ciò, ho bisogno di un sistema per generare un token all'accesso iniziale (autenticazione) e quindi utilizzare questo token per tutte le chiamate successive, suppongo, per convalidare l'autenticazione e consentire l'esecuzione del metodo.

Chiunque ha suggerimenti o suggerimenti su come procedere? 1) Genera un token e cosa è coinvolto in un token sicuro? 2) Quanto tempo è il bene gettone per, alcuni utenti possono utilizzare la loro applicazione per ore e forse anche "sleep" il loro computer

Grazie per i consigli.

+1

La mia domanda è più su quale sia il modo migliore per trasportare questo token avanti e indietro e con tutte le chiamate, non tanto su come autenticarsi. Una volta che il server genera questo token (classe serializzata) qual è il modo migliore per collegarlo a tutte le chiamate successive? Come parametro per i metodi o può essere allegato come intestazione o qualcosa di simile in modo che sia trasparente a tutti i metodi (contratti di servizio) – Neal

risposta

15

Se si sta utilizzando solo un gettone che è dato dal server sulla autenticazione iniziale, può essere usato per qualsiasi richiesta se è stato intercettato. La tua unica difesa è il tempo di scadenza.

Oltre a ciò, dipende dalle opzioni di implementazione.

Un sistema più sicuro è quello di aggiungere un timestamp (ed eventualmente un nonce) per ogni richiesta, segno che, e comprendono che con ogni richiesta. Richiede che il client gestisca le credenziali di autenticazione, conosca l'implementazione della firma e firma ogni richiesta.

È possibile alternare il server all'autenticazione di ogni richiesta (che potrebbe essere eseguita con OpenID) oppure distribuire un numero di token e rianalizzarsi quando ne sono necessari altri (operazione che potrebbe essere eseguita con OAuth). Se il cliente può memorizzare credenziali, queste possono essere invisibili all'utente. Questi sono più complessi, richiedono un trasporto crittografato come SSL per alcune interazioni e un client che può parlare di reindirizzamenti HTTP e gestire i cookie o altri stati memorizzati. Il cliente non dovrebbe sapere come firmare, ma se si può fare SSL, probabilmente non è necessario la complessità in primo luogo.

Se non è necessario essere client-agnostici, è probabile che si desideri firmare le richieste.

Per le implementazioni di firma, esempi e le biblioteche, guarda Amazon Web Services, OpenID, OAuth o.

Per quanto riguarda il tempo di scadenza del token, dipende dalle vostre esigenze. Una vita più lunga dei token aumenta gli attacchi di ripetizione della finestra. Un nonce rende un token monouso, ma richiede più stato sul server.

3

Si consiglia di verificare OAuth. È uno standard per l'autenticazione API, probabilmente puoi semplicemente collegare un'implementazione esistente al tuo servizio.

+0

Il protocollo OAuth consente di impostare i parametri a proprio piacimento. Ti suggerisco di consultare alcuni fornitori di servizi e di verificare cosa hanno fatto con OAuth. http://wiki.oauth.net/ServiceProviders –