Come configurare i servizi RESTful sicuri con WCF usando username / password + SSL

Question

Sto cercando di scrivere un file di configurazione che consenta i servizi RESTful in WCF, ma voglio ancora la possibilità di "accedere" al provider di appartenenza per l'autenticazione con nome utente / password.

Il seguito fa parte della mia configurazione attuale usando il binding basicHttp o wsHttp senza WS Security, come cambierà con i servizi basati su REST?

    <bindings>
        <wsHttpBinding>
            <binding name="wsHttp">
                <security mode="TransportWithMessageCredential">
                    <transport/>
                    <message clientCredentialType="UserName" negotiateServiceCredential="false" establishSecurityContext="false"/>
                </security>
            </binding>
        </wsHttpBinding>
        <basicHttpBinding>
            <binding name="basicHttp">
                <security mode="TransportWithMessageCredential">
                    <transport/>
                    <message clientCredentialType="UserName"/>
                </security>
            </binding>
        </basicHttpBinding>
    </bindings>
    <behaviors>
        <serviceBehaviors>
            <behavior name="NorthwindBehavior">
                <serviceMetadata httpGetEnabled="true"/>
                <serviceAuthorization principalPermissionMode="UseAspNetRoles"/>
                <serviceCredentials>
                    <userNameAuthentication userNamePasswordValidationMode="MembershipProvider"/>
                </serviceCredentials>
            </behavior>
        </serviceBehaviors>
    </behaviors>

Answer 1

AGGIORNAMENTO 23/01/2012

Da quando ho scritto questa domanda ho visto un approccio molto migliore per proteggere REST come i servizi web in natura. Sembrava complesso quando ne ho sentito parlare per la prima volta, ma l'idea è semplice e su tutto il web sia per i servizi web che per altre comunicazioni sicure.

Richiede l'uso di chiavi pubbliche / private.

1.) ogni utente (cliente) dell'endpoint dovrà registrarsi con il servizio Web REST

• a.) dai a questo utente una chiave privata con cui non dovrebbe essere condivisa chiunque
• b.) si genera anche una chiave pubblica che può passare attraverso il filo in testo semplice, se necessario (questo verrà utilizzato anche per identificare il client)

2.) ogni richiesta dell'utente deve generare un hash per firmare la richiesta

• a.) Un esempio di questo potrebbe apparire come: chiave privata + un timestamp + payload codificato (se abbastanza piccolo come una semplice informazione utente da aggiornare ad esempio)
• b.) prendi questi 3 (o qualunque cosa tu abbia deciso) e generi un hash a 1 via (usando ad esempio hmac)
• c.) nella richiesta inviata tramite il filo includi la chiave pubblica (in modo che il lato server sappia chi sta tentando di inviare questa richiesta), l'hash che è stato generato con la chiave privata e il timestamp.

3.) l'endpoint del server (il tuo metodo REST) ??dovrà generare un hash usando gli stessi input utilizzati sul client. Questo passaggio dimostrerà che sia il client che il server conoscevano una chiave privata che corrispondeva alla chiave pubblica passata insieme alla richiesta. (questo a sua volta significa che l'utente che invia la richiesta è legittimo in quanto nessun altro potrebbe conoscere la chiave privata)

• a.) cerca la chiave privata dei clienti tramite la chiave pubblica che viene passata durante la richiesta

• b.) accetta gli altri parametri (timestamp e payload codificato) insieme alla chiave privata che hai trovato nel passaggio precedente e usa lo stesso algoritmo per generare un hash a 1 via (di nuovo hmac è quello che ho visto usato nel mondo reale)

• c.) l'hash a 1 via risultante deve corrispondere all'hash inviato tramite il filo, se non rispedire un 400 (o qualunque codice http che ritieni sia una "richiesta errata")

Answer 2

Ecco un podcast sulla protezione dei servizi REST WCF con il provider di appartenenze ASP.net:

http: // channel9. msdn.com/posts/rojacobs/endpointtv-Securing-RESTful-services-with-ASPNET-Membership/

Answer 3

Concordo con Darrel sul fatto che scenari REST complessi su WCF siano una cattiva idea. Semplicemente non è carino.

Tuttavia, Dominick Baier ha alcuni buoni post su questo suo privilegio / p>

Se desideri vedere il supporto per l'autenticazione WSSE con fallback su FormsAuthentication Supporto per ticket su WCF, controlla il codice sorgente di BlogService .

Answer 4

Prima di continuare questo percorso di lotta per implementare REST su WCF, ti consiglio di leggere questo messaggio di Tim Ewald. Sono stato particolarmente colpito dalla seguente dichiarazione:

  

Non sono sicuro di voler basarmi su a   livello progettato per tenere conto di HTTP   parte superiore di un livello progettato per   fattorizzare.

Ho trascorso gli ultimi 12 mesi a sviluppare materiale basato su REST con WCF e questa affermazione si è dimostrata sempre più vera. IMHO ciò che WCF porta sul tavolo è compensato dalla complessità che introduce nel fare il lavoro REST.

Answer 5

Indipendentemente se la comunità ha opinioni contro REST su WCF (Sono personalmente sulla barriera) Microsoft ha fatto scorrere il dito su di esso, http://msdn.microsoft.com/en-us/netframework/cc950529.aspx

Answer 6

Sì, d'accordo con Moto, un link al largo dello Starter Kit WCF è la cosa più vicina che ho visto all'autenticazione delle credenziali usando un'intestazione HTTP personalizzata ( http://msdn.microsoft.com/en-us/library/dd203052.aspx ).

Tuttavia non sono riuscito a dare l'esempio.

Answer 7

Prova custombasicauth @ codeplex