Ho un servizio di riposo WCF che verrà consumato da più client. Le informazioni restituite dal cliente mi impongono di sapere chi sono, in modo da poter restituire informazioni specifiche per loro.
È il modo migliore per avvicinarsi a questo tipo di design per autenticarli e restituire un token per la loro sessione, quindi passare questo token insieme ad ogni richiesta?
Grazie.
Se stai cercando idee sulla sicurezza per i servizi web REST, guarda le specifiche OpenAuth che descrivono "l'handshake".
La creazione di servizi Web conformi agli standard di OpenAuth è probabilmente uno dei modi più sicuri in cui ciò può essere fatto. Può darti idee sull'autenticazione, strategie di autorizzazione.
Quello che segue è un esempio tratto dall'intestazione Autorizzazione in GET o POST:
Authorization: OAuth
oauth_consumer_key="xxxxxxxxxxxx",
oauth_token="xxxxxxxxxxxx",
oauth_nonce="xxxxxxxxxxxx",
oauth_timestamp="1184242096",
oauth_signature_method="HMAC-SHA1",
oauth_version="1.0",
oauth_signature="xxxxxxxxxxxxxxxxxx"
Non ho intenzione di entrare in tutti i dettagli di OpenAuth ma essenzialmente permette a un client di fornire una chiave utente che identifica il client, un token che identifica l'utente e una firma che rappresenta i byte codificati Base64 della crittografia firma per verificare che la richiesta non sia stata alterata o alterata durante il trasporto.
Costruire la stringa di firma di solito implica la combinazione codificata per cento dell'intera richiesta, i parametri, così come la chiave del consumatore, il token, il nonce e un segreto del consumatore che il cliente dovrebbe tenere al sicuro. Una volta che questa stringa di firma è stata creata e codificata per cento, può essere crittografata e quei byte crittografati possono essere costruiti in una stringa codificata Base64 inclusa nell'intestazione Autorizzazione.
Se esegui questa operazione su SSL, questo è senza dubbio uno dei modi più sicuri per gestire l'autenticazione / l'autorizzazione di un servizio web basato su REST.
A corto di andare con certificati o OpenID, ho trovato che un approccio basato su token è la soluzione più semplice. In un'app di servizio aziendale su cui ho lavorato, disponevamo di un servizio di autenticazione che esponeva un endpoint REST per l'autenticazione e rispondeva con un token che veniva poi passato in un'intestazione con tutte le richieste successive ad altri endpoint. Ogni operazione controllerebbe l'intestazione del token e intraprendere l'azione appropriata in base al fatto che fosse presente o meno e, se presente, se il token rappresentasse un utente con l'autorizzazione richiesta.
Il mio suggerimento è di esaminare un modello di sicurezza basato sulle attestazioni. Innanzitutto, rende questo MOLTO più facile da implementare in quanto è possibile mantenere il server stateless incapsulando tutte le informazioni di reclamo dell'utente all'interno del token. E, in secondo luogo, è il modello in cui si stanno muovendo Microsoft e molti altri. Se stai facendo lo sviluppo .NET, guarda in Windows Identity Foundation. Questo è attualmente un add-on per il framework .NET ma sarà integrato in Windows 8 (ed è, di fatto, il modello di sicurezza predefinito in .NET 4.5).
Un modo possibile per farlo sarebbe con un token di sessione basato su cookie (o basato su parametri URL), come suggerito. Tuttavia, passare un token di sessione come quello viola il principio HATEOAS . Per un "vero" servizio REST, dovresti evitare di mantenere lo stato del server.
Se utilizzi HTTPS, potrebbe essere saggio prendere in considerazione l'uso dell'autorizzazione / autenticazione incorporata (Sec. 14.8) meccanismi in HTTP. Vale a dire, utilizzando le intestazioni WWW-Authenticate e Authorization per passare le autorizzazione di base al server di informazioni su ogni richiesta. Ciò ti consente di mantenere l'apolidia, ma poiché stai utilizzando HTTPS, è anche sicuro. Se non stai utilizzando HTTPS, forse dovresti essere:).
L'utilizzo di OAuth con il meccanismo HTTP è un'altra alternativa a Basic Auth, ma la sua complessità non è necessaria se stai già crittografando il canale con HTTPS. Poiché le richieste OAuth non possono essere riprodotte e non rivelano la chiave, sono accettabili rispetto a HTTP vecchio-semplice, mentre l'autenticazione di base non lo è.
Quindi, in sintesi:
WWW-Authenticate e Authorization per condividere le informazioni sulle credenziali Mi rivolgo a HTTPS e Basic Auth perché il supporto dei client Web è onnipresente. Preferisco anche non implementare una sessione se non dovessi farlo. È una complessità inutile e non è veramente riposante. Le richieste di REST devono essere autonome, pertanto si inviano le credenziali e qualsiasi altra informazione necessaria per creare la richiesta. Tuttavia, potrebbero esserci motivi / requisiti che richiedono di compromettere OAuth piuttosto che HTTPS e Basic Auth.
Le risorse dovrebbero avere gli acl appropriati per controllare chi può e non può accedervi. Una richiesta viene ricevuta da un utente autenticato che viene soddisfatta solo se l'utente ha accesso alla risorsa.
Leggi altre domande sui tag rest authentication wcf authorization