Analógico do WCF 4.0 ao RequestInterceptor do WCF REST Starter Kit?

StackOverflow https://stackoverflow.com/questions/6023121

  •  14-11-2019
  •  | 
  •  

Pergunta

O WCF 4.0 tem uma classe/módulo/qualquer coisa analógica para o RequestInterceptor do WCF REST Starter Kit?

Foi útil?

Solução

Não há nada que mapeça 1-1 para ele, mas você pode usar um idispatchmessageinspector do núcleo do WCF para implementar a maioria dos cenários para os quais o solicitador faria.O post em http://blogs.msdn.com/b/carlosfigueiraira/Archive/2011/04/19/WCF-Exensibilização-message-Inspectores.aspx tem algumas informações detalhadas sobre os inspetores de mensagens.

Outras dicas

Estou de volta com uma atualização.

Acontece que valorizo ​​​​a simplicidade no código e, depois de resolver esse problema com sucesso, não posso dizer que prefiro isso mais do que o método Query String.Soltar uma única chamada em cada endpoint de serviço que chama um método AuthN junto com o método AuthZ parece mais fácil do que alguns podem acreditar.

De qualquer forma, chega de opiniões...para a solução.A solução está bem sob nossos olhos no Stackoverflow neste link, mas não está bem descrita em nosso contexto... então darei crédito a "user634119" pelo código de exemplo encontrado aqui:Cabeçalhos em OperationContext

Primeiro, precisamos adicionar um serviceBehavior ao nosso arquivo web.config:

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

Em seguida, crie uma classe (chamada BasicAuthorization conforme referenciado no bloco serviceBehaviors acima):

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

Em seguida, crie uma classe de autenticação:

// 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
    }
}

No método Authenticate, use HttpRequestMessageProperty para extrair os detalhes do cabeçalho da solicitação e executar as mesmas três etapas descritas na minha primeira resposta.

Eduardo, você perguntou: @carlosfigueira: posso usá-lo para implementar um subsistema de autenticação?

Eu estou trabalhando nesse mesmo problema e tenho pelo menos uma solução (descrita abaixo) para você e um próximo cabeçalho de autorização baseado em cabeçalho (que eu acredito é o que você está pensando em "interceptar").

A maneira mais simples de proteger um endpoint baseado no modelo de programação WCF 4 REST REST é este:

    .
  1. Emita uma chave secreta compartilhada e uma chave de API para cada cliente para usar como credenciais. A chave da API é realmente o mesmo que um nome de usuário.
  2. Execute todos os endpoints sobre SSL para garantir que você sempre tenha canal / mensagem / segurança de dados
  3. Exigir que os clientes usem o segredo compartilhado para gerar uma cadeia de assinatura HMAC-SHA1 (ou equiv) que inclua um timestamp e sua chave de API.
  4. Exigir que o cliente passe todos os 3 desses como parâmetros de strings de consulta em todas as solicitações :
    • assinatura
    • timestamp
    • chave da API
    • exemplo: https://127.0.0.1/restendpoint?sig= {sigstring} & apikey= {apikey} & timestamp= {timestamp} e todos os seus outros parâmetros aqui ...
    • no seu lado de serviço, implemente um método de autenticação que leva todas as 3 cordas e depois:
      • procura a chave da API e retorna o segredo compartilhado do cliente que você tem em um dB ou em outro lugar.
      • Compare o timestamp contra datetime.now para garantir que a solicitação não seja mais de 15 minutos de idade para afastar ataques de repetição.
      • Usando essas 3 cordas, recrie a string de assinatura e compare a sua para aquela passada pelo cliente.
      • Se eles corresponderem, o solicitante é autêntico.

        Agora, a melhor maneira de fazer isso é usando o cabeçalho de solicitação de autorização HTTP para armazenar essas 3 cordas e ter um processo global do interceptor-ish assistir todas as solicitações. Isso impediria o potencial de um endpoint exposto sem um bloco de autenticação (bem, pelo menos é menos provável).

        Problema com a utilização da sequência de consulta para transportar todas as esta informação é a string de consulta tem um comprimento máximo de 2K (que varia por cliente / navegador) e a string de consulta é muito difícil de ler quando depurando ... mas apenas se acostumar com isto.

        Alguns pensam que uma maneira mais sofisticada de fazer isso é um modelo STS onde você precisa que o cliente passe essas 3 cadeias de autenticação para um endpoint de serviço de token de segurança. A mensagem de resposta passaria de volta um token de sessão que o cliente passaria em cada chamada em vez das 3 cordas. É verdade que para o cliente não há necessidade de gerar uma assinatura HMAC Hash em cada chamada, mas o lado do servidor deve ainda autenticar o token e o conceito de sessão suporta o comportamento sem estado tranquilo limpo.

        Eu farei o meu melhor para postar blocos de código que implementam tanto a sequência de consulta quanto as metodologias de cabeçalho de autenticação.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top