wcf cosa - Best practice per la protezione di un'API / servizio web REST




9 Answers

Come detto, Amazon S3 è un buon modello con cui lavorare. Le loro firme di richiesta hanno alcune caratteristiche (come l'incorporazione di un timestamp) che aiutano a prevenire la riproduzione di richieste accidentali e dannose.

La cosa bella di HTTP Basic è che praticamente tutte le librerie HTTP lo supportano. Ovviamente, in questo caso, è necessario richiedere SSL perché inviare password in chiaro su Internet è quasi universalmente una cosa negativa. È preferibile eseguire il Digest di base quando si utilizza SSL perché, anche se il chiamante sa già che sono richieste le credenziali, Digest richiede un ulteriore roundtrip per scambiare il valore nonce. Con Basic, i chiamanti inviano semplicemente le credenziali la prima volta.

Una volta stabilita l'identità del cliente, l'autorizzazione è in realtà solo un problema di implementazione. Tuttavia, è possibile delegare l'autorizzazione ad altri componenti con un modello di autorizzazione esistente. Ancora una volta la cosa bella di Basic qui è che il tuo server finisce con una copia in chiaro della password del client che puoi semplicemente passare ad un altro componente all'interno della tua infrastruttura, se necessario.

sono example

Quando si progetta un'API o un servizio REST esistono delle best practice consolidate per la gestione della sicurezza (autenticazione, autorizzazione, gestione dell'identità)?

Quando si crea un'API SOAP si ha WS-Security come guida e molta letteratura sull'argomento. Ho trovato meno informazioni sulla protezione degli endpoint REST.

Mentre capisco che REST intenzionalmente non ha specifiche analoghe a WS- * spero che siano emerse migliori pratiche o modelli raccomandati.

Qualsiasi discussione o link a documenti pertinenti sarebbe molto apprezzato. Se è importante, utilizzeremo WCF con i messaggi serializzati POX / JSON per le nostre API / servizi REST creati utilizzando la v3.5 di .NET Framework.




Puoi anche dare un'occhiata a OAuth , un protocollo aperto emergente per l'autorizzazione basata su token che si rivolge in modo specifico alle http apis.

È molto simile all'approccio adottato da flickr e ricorda l' apis del latte "resto" (non necessariamente buoni esempi di apis riposati, ma buoni esempi dell'approccio basato sui token).




Tutti in queste risposte hanno trascurato il vero controllo / autorizzazione degli accessi.

Se ad esempio le tue API / servizi web REST riguardano il POSTing / GETing delle cartelle cliniche, potresti voler definire la polizza di controllo degli accessi su chi può accedere ai dati e in quali circostanze. Per esempio:

  • i medici possono ottenere la cartella clinica di un paziente con cui hanno una relazione di assistenza
  • nessuno può inviare dati medici al di fuori delle ore di pratica (ad esempio da 9 a 5)
  • gli utenti finali possono ottenere le cartelle cliniche di loro proprietà o le cartelle cliniche dei pazienti per i quali sono tutori
  • gli infermieri possono AGGIORNARE la cartella clinica di un paziente che appartiene alla stessa unità dell'infermiere.

Al fine di definire e implementare tali autorizzazioni a grana fine, sarà necessario utilizzare un linguaggio di controllo degli accessi basato su attributi chiamato XACML, il linguaggio di markup del controllo di accesso eXtensible.

Gli altri standard qui sono i seguenti:

  • OAuth: id. federazione e delega di autorizzazione, ad esempio lasciando che un servizio agisca per mio conto su un altro servizio (Facebook può postare sul mio Twitter)
  • SAML: identity federation / web SSO. SAML parla molto di chi è l'utente.
  • Standard WS-Security / WS- *: si concentrano sulla comunicazione tra i servizi SOAP. Sono specifici del formato di messaggistica a livello di applicazione (SOAP) e trattano aspetti di messaggistica, ad es. Affidabilità, sicurezza, riservatezza, integrità, atomicità, eventi ... Nessuno copre il controllo degli accessi e tutti sono specifici per SOAP.

XACML è indipendente dalla tecnologia. Può essere applicato a applicazioni Java, .NET, Python, Ruby ... servizi Web, API REST e altro ancora.

Le seguenti sono risorse interessanti:




Ho usato OAuth un paio di volte e ho usato anche altri metodi (BASIC / DIGEST). Suggerisco di cuore OAuth. Il seguente link è il miglior tutorial che ho visto su OAuth:

http://hueniverse.com/oauth/guide/




Grazie per l'eccellente consiglio. Abbiamo finito con l'utilizzo di un'intestazione HTTP personalizzata per passare un token di identità dal client al servizio, in preparazione per l'integrazione della nostra API RESTful con l'imminente framework Zermatt Identity di Microsoft. Ho descritto il problema here e la nostra soluzione here . Ho anche preso il consiglio di tweakt e ho acquistato RESTful Web Services - un ottimo libro se stai costruendo una API RESTful di qualsiasi tipo.




Consiglierei OAuth 2/3. Puoi trovare maggiori informazioni su http://oauth.net/2/




Ho cercato molto sulla sicurezza di ws e abbiamo finito con l'utilizzo di token tramite cookie dal client al server per autenticare le richieste. Ho utilizzato la sicurezza di primavera per l'autorizzazione delle richieste in servizio perché dovevo autenticare e autorizzare ogni richiesta in base a criteri di sicurezza specificati che erano già presenti nel DB.




Voglio aggiungere (in linea con stinkeymatt), la soluzione più semplice sarebbe quella di aggiungere certificati SSL al tuo sito. In altre parole, assicurati che il tuo URL sia HTTPS: //. Ciò coprirà la sicurezza del trasporto (bang for the buck). Con l'URL di RESTful, l'idea è di mantenerla semplice (a differenza di WS * security / SAML), è possibile utilizzare oAuth2 / openID connect o anche Basic Auth (in casi semplici). Ma avrai ancora bisogno di SSL / HTTPS. Si prega di verificare la sicurezza di API Web ASP 2 qui: http://www.asp.net/web-api/overview/security (Articoli e video)




Per Web Application Security, dovresti dare un'occhiata a OWASP ( https://www.owasp.org/index.php/Main_Page ) che fornisce i cheatsheet per vari attacchi di sicurezza. Puoi incorporare il maggior numero possibile di misure per proteggere la tua Applicazione. Per quanto riguarda la sicurezza dell'API (autorizzazione, autenticazione, gestione dell'identità), esistono diversi modi, come già menzionato (base, digest e OAuth). Esistono fori di loop in OAuth1.0, quindi è possibile utilizzare OAuth1.0a (OAuth2.0 non è ampiamente adottato a causa di problemi con le specifiche)




Related

wcf security rest authorization rest-security