Cenários de implementação de serviços com WCF - Parte 2 : Web Services Corporativos
Web Services Corporativos
Olá pessoal, tudo certo?
Vamos falar hoje sobre um cenário muito comum em ambientes de produção nas empresas, que são os Web Services Corporativos. Nesse cenário, encontramos suporte para web services simples baseados em protocolo SOAP ou implementações avançadas sobre os padrões WS-* ( WS-I : Web Services Interoperability Organization ).
Desde o final dos anos 90 encontramos Web Services sendo usados em diversas soluções para a interoperabilidade entre sistemas, permitindo a troca de mensagens entre plataformas heterogêneas. Grande parte dessa produtividade é devido o uso dos documentos WSDL - Web Service Description Language, que descrevem as políticas e o metadado do serviço envolvido.
WCF suporta nativamente a tecnologia de Web Services, em diferentes alternativas de implementação, suportando versões consumidas por clientes JAVA ou outras plataformas não Microsoft, assim como clientes .NET 2.0. Também permite o consumo através de clientes Web Services Enhancements (WSE) 3.0 e clientes .NET 3.x.
Em muitos cenários, é possível migrar ASP.NET Web Services (ASMX) e Web Services WSE 3.0 para serviços WCF sem impacto para os clientes envolvidos.
A figura abaixo apresenta uma visão sobre os tipos de clientes envolvidos no cenário de Web Services Corporativos:
Note que é possível combinar diferentes protocolos de acordo com o tipo de cliente envolvido. Além disso, vale lembrar que para compatibilidade histórica, o SOAP 1.1 (ou Basic Profile 1.1) é o transporte indicado para o acesso aos serviços WCF. Assim, para clientes ASMX, usamos o protocolo SOAP 1.1; para clientes ASMX + WSE, usamos o protocolo SOAP 1.2 + WS-Addressing; e para clientes WCF, usamos SOAP 1.2 + WS-Addressing + WS-SecureConversation + WS-ReliableMessaging, para ilustrar.
Sobre os protocolos suportados pelo WCF temos:
| Categoria | Protocolo Suportado |
| Messaging | SOAP, WS-Addressing, MTOM |
| Metadada | WSDL, WS-MetadataExchange, WS-Policy |
| Security | WS-Security, WS-SecureConversation, WS-Trust |
| Reliability | WS-ReliableMessaging |
| Transactions | WS-Coordination, WS-AtomicTransaction |
Considerando nossa proposta, vamos dar uma olhada nas principais características e configurações presentes para o cenário de Web Services em WCF. Pensando sobre a segurança aplicada aos Web Services, podemos identificar 3 configurações possíveis:
- Web Services com passagem de usuário e senha sobre SSL - Secure Sockets Layer
- Web Services com passagem de usuário e senha sobre segurança de mensagens
- Web Services com segurança de sessão e mecanismo de sessão confiável ativada
Para cada opção acima, teremos configurações distintas, conforme vemos nas tabelas a seguir:
Web Services com passagem de usuário e senha sobre SSL - Secure Sockets Layer:
| Característica | Descrição |
Hosting |
IIS 6 sobre Windows Server 2003, IIS 7 sobre Windows Server 2008 |
Protocolo de Transporte |
HTTPS (SSL) |
Protocolo de Mensagens |
SOAP + WS-Addressing |
Autenticação |
Usuário e Senha são fornecidos como parte da mensagem SOAP, baseada em WS-Security e UsernameToken Profile. |
Autorização |
Um armazenamento de credenciais é normalmente indicado, desde que os usuários não façam parte de um domínio Windows. |
Segurança |
Um certificado SSL é fornecido para segurança de mensagens. |
A figura abaixo ilustra o cenário acima, onde a segurança é obtida através do canal SSL, veja:
by M. L. Bustamente
Web Services com passagem de usuário e senha sobre segurança de mensagens:
| Característica | Descrição |
Hosting |
IIS 6 sobre Windows Server 2003, IIS 7 sobre Windows Server 2008 |
Protocolo de Transporte |
HTTP |
Protocolo de Mensagens |
SOAP + WS-Addressing |
Autenticação |
Usuário e Senha são fornecidos como parte da mensagem SOAP, baseada em WS-Security e UsernameToken Profile. |
Autorização |
Um armazenamento de credenciais é normalmente indicado, desde que os usuários não façam parte de um domínio Windows. |
Segurança |
Uso de protocolo WS-Security sobre certificados X.509 para a segurança de mensagens. |
Para ilustrar o cenário acima, onde temos a segurança de mensagens com o uso do WS-Security, veja a figura abaixo:
by M. L. Bustamante
Web Services com segurança de sessão e mecanismo de sessão confiável ativada:
| Característica | Descrição |
Hosting |
IIS 6 sobre Windows Server 2003, IIS 7 sobre Windows Server 2008 |
Protocolo de Transporte |
HTTP |
Protocolo de Mensagens |
SOAP + WS-Addressing |
Autenticação |
Usuário e Senha são fornecidos como parte da mensagem SOAP, baseada em WS-Security e UsernameToken Profile. WS-SecureConversation é ativado para otimizar a autenticação. |
Autorização |
Um armazenamento de credenciais é normalmente indicado, desde que os usuários não façam parte de um domínio Windows. |
Segurança |
Uso de protocolo WS-Security sobre certificados X.509 para a segurança de mensagens. |
| Reliability (Confiabilidade) | Protocolo WS-ReliableMessaging é utilizado. |
Como ilustração, a figura abaixo apresenta o modelo de acesso ao serviço WCF, considerando um Web Services avançado, onde aplicamos uma sessão confiável, certificados e um repositório de credenciais externo, veja:
by M. L. Bustamante
Fonte: Bustamente, M.L., Windows Communication Foundation: Application Deployment Scenarios , May 2008.
Qual opção de configuração devemos adotar? De fato, isso irá depender dos recursos disponíveis e aderência do projeto ao modelo de segurança implementado acima.
Note que cada cenário adiciona aspectos de desempenho, complexidade e experiência do usuário em graus diferentes. Por exemplo, para o cenário mais avançado, temos um impacto no tamanho de mensagens, que deve adicionar os padrões WS-Security, WS-SecureConversation e WS-ReliableMessaging (WS-RM) . Ao mesmo tempo, WS-RM adiciona um mecanismo de confiabilidade na troca de mensagens, com uma sequência de requests/reponses que aumenta o grau de confiança entre cliente e servidor. Esse mesmo tipo de avaliação deve ser feito para as outras configurações, avaliando seus prós e contras.
Desse modo, passamos por alguns aspectos importantes na definição de arquiteturas com Web Services Corporativos e suas configurações.
No próximo post, vamos olhar um cenário relativamente recente: serviços para Web 2.0. Fiquem ligados.
Por enquanto é só! Até o próximo post :)
Waldemir.
Comments
Anonymous
July 01, 2008
Boas Waldemir, Uma das coisas que o pessoal fazia (ou ainda faz) nos tradicionais Web Services (fornecidos desde a versão 2002 do VS.NET) é a passagem do username e password via SoapHeader. Apesar de funcionar, isso somente tem alguma segurança quando você corre o serviço sob HTTPS ou utiliza WSE que, na maioria dos casos que vi, não acontecia. Já o WCF obriga-nos a utilizar um certificado quando utilizamos a segurança baseada em mensagens, justamente para garantir a segurança, mesmo quando não corre sob SSL. E é essa "constraint" que faz muitos reclamarem. Att,Anonymous
July 01, 2008
Olá Israel, tudo certo? Obrigado pelos comentários no blog! De fato, a passagem de username e password via SoapHeader sobre HTTP apenas não fornece segurança alguma, já que as strings de username e password irão trafegar em texto aberto, como no exemplo a seguir: POST /UsernamePassowordServiceExemple/Service.asmx HTTP/1.1 Host: localhost Content-Type: text/xm; charset=utf-8 Content-Length: length SOAPAction: "http://localhost.net/AddTwoNumbers" <?xml version="1.0" enconding="utf-8"?> <soap:Envelope xmlns:xsi="'>http://www.w3.org/2001/XMLSchema-instance"> <soap:Header> <ServiceAuthHeader xmlns="'>http://localhost.net/"> <Username>string</Username> <Password>string</Password> </ServiceAuthHeader> </soap:Header> <soap:Body> <AddTwoNumbers xmlns="'>http://localhost.net/"> <x>int</x> <y>int</y> </AddTwoNumbers> </soap:Body> </soap:Envelope> Temos uma discussão sobre esse cenário aqui: Ref.: http://www.keithelder.net/blog/archive/2007/01/06/Securing-Web-Services-With-Username-and-Password.aspx Veja que o autor é categórico quando afirma que sem o suporte SSL, o modelo de autenticação acima não irá fornecer a funcionalidade esperada. Quando penso nos possíveis modos de ataque, lembro ainda do famoso STRIDE - Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege, que consolida os principais tipos de ataque possíveis sobre uma aplicação. Sobre STRIDE recomendo um blog interessante, veja: Ref.: http://blogs.msdn.com/sdl/archive/2007/09/11/stride-chart.aspx A exigência do uso de certificado não é feita pelo WCF, mas sim pelo modelo de segurança de mensagens sobre Soap, conforme especificação WS-I (basic profile). É parte dos elementos para a garantia do CIA - Confidentiality, Integrity e Authentication. Veja o WSHTTPBinding por exemplo. Por default, ele usa o modelo de segurança por mensagens (message-level security), assumindo que o serviço e o cliente irão se autenticar utilizando credenciais. Por default também, o corpo da mensagem e uma parte do header são assinados para se manter a integridade da mensagem (especificamente, ele assina os headers WS-Addressing e encripta todo o header da aplicação). Da mesma forma, o corpo da mensagem é encriptado. Isso previne ataques ao corpo da mensagem ou qualquer tipo de inspeção de messagem Soap. Porém, se não queremos esse nível de segurança, podemos desligar algumas características ou trocá-las, conforme a necessidade. Pensando em casos de exceção, é possível ainda criar customizações de channels e bindings, que oferecem um mix de segurança entre transporte e mensagens sobre WCF, tornando o modelo muito flexível. Sobre essas customizações, recomendo a leitura do seguinte artigo sobre segurança no WCF, veja: Security in Windows Communication Foundation by Keith Brown Ref.: http://msdn.microsoft.com/en-us/magazine/cc163570.aspx É uma discussão bem legal! :) Por enquanto é só! Abraço Grande! Waldemir.