WCF 4.0 analogico WCF REST Starter Kit RequestInterceptor?

Question

Non WCF 4.0 avere un analogico di classe/modulo/quello-che-WCF REST Starter Kit RequestInterceptor?

Answer 1

Non c'è nulla che mappasse 1-1 ad esso, ma è possibile utilizzare un IDispatchMessageSeSpector da WCF Core per implementare la maggior parte degli scenari per i quali lo spedirebbe il requestInSpector.Il post a http://blogs.msdn.com/b/carlosfigueira/archive/2011/04/19/WCF-EXTIsibility-Message-inspectors.aspx ha alcune informazioni dettagliate sugli ispettori dei messaggi.

Answer 2

Sono tornato con un aggiornamento.

Mi capita di valutare la semplicità nel codice e dopo aver risolto con successo questo problema, non posso dire che lo preferisco più del metodo della stringa della query. Lasciare cadere una singola chiamata in ogni endpoint del servizio che chiama un metodo AUTN a fianco del metodo Authz sembra più facile di quanto potrebbe credere.

comunque, abbastanza delle opinioni ... sulla soluzione. La soluzione è proprio sotto i nostri occhi su Stackoverflow in questo collegamento ma non ben descritto nel nostro contesto ... quindi darò credito a "user634119" per il codice di esempio trovato qui: Intestazioni in OperationContext

In primo luogo, dobbiamo aggiungere un serviceBehavior al nostro file web.config:

<behaviors>
  <serviceBehaviors>
    <behavior>
      <serviceAuthenticationManager serviceAuthenticationManagerType="WCF.BasicAuthorization, WCF"></serviceAuthenticationManager>
      <serviceAuthorization impersonateCallerForAllOperations="false" principalPermissionMode="Custom" serviceAuthorizationManagerType="WCF.BasicAuthentication, WCF">
      </serviceAuthorization>
    </behavior>
  </serviceBehaviors>
</behaviors>

.

Avanti Fai una classe (chiamata Basicauthorization come riferimento nel blocco di ServiceBehaViors sopra):

//Authorize the call against the URI resource being requested...
public class BasicAuthorization : ServiceAuthorizationManager
{
    public override bool CheckAccess(OperationContext operationContext, 
    ref Message message)
    {
        //some code
    }
}

.

Avanti Fai una classe di autenticazione:

// Authenticate the header signature as described in my previous post
public class BasicAuthentication : ServiceAuthenticationManager
{
    public override ReadOnlyCollection<IAuthorizationPolicy> Authenticate(
        ReadOnlyCollection<IAuthorizationPolicy> authPolicy, Uri listenUri, 
        ref Message message)
    {
        //some code
    }
}

.

Nel metodo Autenticato, utilizzare HTTPRequestMessageProperty per estrarre l'intestazione richiesta Dettagli ed eseguire gli stessi 3 passaggi descritti nella mia prima risposta.

Answer 3

Eduardo, che hai chiesto:@carlosfigueira:La posso usare per implementare un sottosistema di autenticazione?

Sto lavorando su questo problema e avere almeno una soluzione (descritta di seguito) e di un imminente Intestazione di Autorizzazione base di uno (che io credo è quello che si sta pensando di "intercettare").

Il modo più semplice per fissare un WCF 4 RESTO WebHttp modello di programmazione basato su endpoint è questo:

1. Problema di una Chiave Segreta Condivisa e di una Chiave API per ogni client da utilizzare come credenziali.La chiave API è lo stesso di un nome utente.
2. Eseguire tutti endspoints su SSL per garantire sempre di avere un canale/messaggio/sicurezza dei dati
3. I client devono utilizzare un Segreto Condiviso per generare un HMAC-SHA1 (o equivalente) hash della stringa della firma che include un timestamp e la loro Chiave API.
4. È necessario che il client passa tutti e 3 di questi, come le stringhe di query parametri in ogni richiesta:
   • Firma
   • Timestamp
   • API Key
   • Esempio: https://127.0.0.1/RestEndpoint?Sig={sigString}&ApiKey={apiKey}&TimeStamp={timeStamp}&Tutti gli altri parametri...
5. Sul lato di servizio, implementare un metodo di Autenticazione che prende tutte e 3 le stringhe e quindi:
   • Cerca la chiave API e restituisce al client segreto condiviso che si sono in un DB o da qualche altra parte.
   • Confronta il timestamp contro DateTime.Ora per assicurarsi che la richiesta non più di 15 minuti il vecchio, per respingere gli attacchi di tipo replay.
   • Utilizzando queste 3 stringhe, ricreare la stringa della firma e confrontare proprio a quello passato dal client.
   • Se corrispondono, il richiedente è autentica.

Ora, il modo migliore per farlo è tramite l'HTTP di Richiesta di Autorizzazione di Intestazione per memorizzare queste 3 stringhe e globale, interceptor-ish processo di guardare tutte le richieste.Questo permetterebbe di evitare il potenziale per un esposto endpoint senza autenticazione di un blocco (beh, almeno è meno probabile forse).

Problema con utilizzando la stringa di query per eseguire tutte queste informazioni è la stringa di query è un 2k max lunghezza che varia dai client/browser) e la stringa di query diventa davvero difficile da leggere quando il debug...ma basta farci l'abitudine.

Alcuni ritengono che un modo più sofisticato per fare questo, è un M modello in cui è necessario che il client di passare queste 3 stringhe di autenticazione di un Servizio Token di Sicurezza endpoint.La risposta messaggio per passare nuovamente un token di sessione che il cliente possa passare su ogni chiamata in luogo delle 3 corde.È vero che per il cliente non c'è bisogno di generare un HMAC hash la firma su ogni chiamata, ma il server deve ancora autenticazione token e il concetto di sessione falli fino clean Riposante stateless comportamento.

Farò del mio meglio per inserire blocchi di codice che implementa sia la stringa di query e l'auth intestazione metodologie.