Analógico do WCF 4.0 ao RequestInterceptor do WCF REST Starter Kit?
-
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?
Solução
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:
- .
- 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.
- Execute todos os endpoints sobre SSL para garantir que você sempre tenha canal / mensagem / segurança de dados
- 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.
- 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.