Curso de Mestrado em Sistemas de Dados e Processamento Analtico

Segurana e Privacidade em Sistemas de Armazenamento e Transporte de Dados

Segurana em Web Services

Carla Aliete Santos

ndice

Introduo...............................................................................................................4 1.1. O que um Web Service ................................................................................................ 4 1.2. Quando usar? .................................................................................................................. 4 2. WS Soluo..........................................................................................................5 2.1. O que h de errado no SSL? ........................................................................................... 5 3. Segurana: Solues ...........................................................................................10 3.1. WS-* Especificaes .................................................................................................... 10 3.2. WS-Security e o SOAP (Simple Object Access Protocol) ........................................... 11 3.3.1 Security Tokens para o elemento <Security> .............................................................. 13 3.3.2 Encriptao XML......................................................................................................... 15 4. .NET Web Services e WSE...................................................................................17 4.1. WS-Trust....................................................................................................................... 19 4.2. WS-Federation .............................................................................................................. 19 4.3. WS-Secure Conversation .............................................................................................. 20 4.4. WS-Privacy ................................................................................................................... 21 5 . Exemplo de um Web Service.................................................................................22 Concluso ....................................................................................................................23 Referncias Bibliogrficas .........................................................................................24

1.

ndice de Figuras
Figura 1 Camada de Protocolos............................................................................................. 4 Figura 2- Mapeamento Web Services <-> .NET ..................................................................... 5 Figura 3 - Cenrio utilizando o HTTPS.................................................................................... 5 Figura 4 Cenrio onde usado o protocolo SOAP............................................................. 6 Figura 5 Entidades envolvidas na chamada a um Web Service....................................... 6 Figura 6 Mensagens trocadas na invocao de um Web Service.................................... 7 Figura 7 Invocao de um Web Service ............................................................................... 8 Figura 8 - Exemplo de um cenrio com domnios de confiana ....................................... 11 Figura 9 Mensagem SOAP ................................................................................................... 12 Figura 10 - Modelo de base para Web Services seguros. .................................................. 13 Figura 11 - < wsse:Security>, para Basic Authentication .................................................... 14 Figura 12 - O WS-Security elemento <BinarySecurityToken> ........................................... 15 Figura 13- Exemplo: Assinatura XML (no SOAP)................................................................. 17 Figura 14 - WS-Security framework ........................................................................................ 18 Figura 15 Policies Assertions................................................................................................. 18 Figura 16 WS-Trust ................................................................................................................ 19 Figura 17 WS-Federation ...................................................................................................... 20 Figura 18 - Exemplo SecurityContextToken .......................................................................... 20 Figura 19 - Normas suportadas nas principais implementaes de servios seguros... 21

1. Introduo
O que um Web Service
O Web Services uma tecnologia de chamada remota de objectos, que permite uma infra-estrutura para criao de aplicaes distribudas (web ou no). Com os Web Service possvel a criao de pequenos mdulos de cdigo reutilizveis e disponibilizados para construo de aplicaes, utilizando protocolos Web como meio de transporte e comunicao. Desta forma consegue-se um alto grau de abstrao em relao a linguagens de programao e plataformas de hardware / software.

Quando usar?
Os Web Services podem ser usados em vrio cenrio, por exemplo, quendo se pretende: Integrar sistemas heterogneos dentro da empresa Integrar sistemas remotos atravs da Internet Integrar diferentes plataformas de hardware / software / SO Fornecer servios a terceiros Web Services so identificados por uma URI(Unique Resource Identifier), e so descritos e definidos usando XML. Um dos motivos que tornam os Web Services atractivos o facto deste modelo ser baseado em tecnologias standards, em particular XML e HTTP. Os Web Services so usados para disponibilizar servios interactivos na WEB, podendo ser acedidos por outras aplicaes. Os Web Services so so uma tecnologia Microsoft, e o seu objectivo que sejam o mais independentes possvel, dai que sejam compostos por linguagens e protocolos abertos e largamente adotados pelo mercado:

Figura 1 Camada de Protocolos

A Figura 2 apresenta os vrios protocolos e em que fase da troca de mensagens esto envolvidos. O que acontece em relao arquitectura .Net da Microsoft, esta suporta todos estes protocolos e linguagens.

Figura 2- Mapeamento Web Services <-> .NET

A .NET Framework fornece um mapeamento bi-direcional entre cada componente da Framework e cada um dos Protocolo.

2. WS Soluo
O que h de errado no SSL?
Na Figura 3 apresenta-se um cenrio da utilizao do HTTPS. O que verificamos que a segurana s garantida em determinado caminho. Desta forma no podemos confiar numa segurana apenas ponto-a-ponto, ainda mais se existirem muitos pontos na rota, torna-se um desafio manter as credenciais. O HTTPS tem como desvantagem ser dependente do protocolo http, e alm disso cifrar a mensagem toda, tornando-se assim excessivo e caro na utilizao de recursos.

Figura 3 - Cenrio utilizando o HTTPS

A soluo encontrada que as credenciais no dependam do canal e transporte, mas sejam integradas na prpria mensagem. Desta forma no importa quantas rotas o caminho tenha, a mensagem ir levar consigo a sua prpria informao de segurana. A Figura 4 mostra um cenrio em que a troca de mensagens feita atravs do protocolo SOAP, que ser abordado mais frente.

Figura 4 Cenrio onde usado o protocolo SOAP

A troca de mensagens utiliza o Protocolo HTTP como camada de transporte, uma vez que as chamadas SOAP no so mais do que chamadas http GET ou POST, e utiliza a porta 80, permitida pelos firewalls. A formatao destas mensagens so em XML Tanto a Figura 5 como a 6 apresentam as entidades envolvidas na chamada a um web Service e como feita a troca de mensagens entre eles.

Figura 5 Entidades envolvidas na chamada a um Web Service

Figura 6 Mensagens trocadas na invocao de um Web Service

WSDL Quando algum cria um Web Service este necessita de ser publicado. Como foi dito, a sua utilizao independente da linguagem em que foi escrito, por isso este deve ser descrito de forma a que qualquer plataforma entenda. O WSDL (Wed Service Description Language) define um sistema para a descrio de servios, baseado em XML. Este XML Schema descreve o formato dos mtodos a serem chamados, parmetros a serem passados, operaes, esquemas de codificao, etc O seu principal objectivo descrever as interfaces apresentadas e apontar a localizao dos seus Web Services, disponveis num local da rede, o qual permite que o cliente aceda de maneira confivel. Por ser um documento XML, a sua leitura torna-se fcil e acessvel. UDI A questo que se coloca agora como encontrar os Web Services? O Universal Description, Discovery, and Integration (UDDI) uma especificao tcnica que tem como objectivo descrever, descobrir e integrar Web Services. Segundo a Organization for the Advancement of Structured Information Standards, um elemento central do grupo de padres que compe a pilha de componentes dos servios web. No momento que construmos um Web Service, necessitamos que os servios sejam acedidos de algum lugar da Internet por um cliente. Uma das maneiras fazer com que a aplicao cliente conhea a URI do servio. Gunzer define UDDI como um padro desenvolvido para fornecer um directrio de busca para os negcios e seus servios. Tem como objectivo ser um mediador do servio, permitindo que os clientes requisitantes encontrem um fornecedor do servio apropriado.

SOAP um dos principais elementos dos Web Services, apesar de no ser necessrio o conhecimento do seu funcionamento para se criar e consumir um Web Service. Porm, o entendimento geral do protocolo til para se lidar com eventuais situaes de erros e problemas com a interoperabilidade entre plataformas no uso de Web Services.

 Service Oriented Architecture Protocol: no caso geral, uma mensagem SOAP representa a informao necessria para invocar um servio ou analisar o resultado de uma chamada e contm informaes especficas da definio da interface do servio. Service Object Access Protocol: representao opcional do SOAP RPC, a mensagem SOAP representa um mtodo de invocao de um objecto remoto, e a serializao da lista de argumentos do mtodo que precisam ser movidos do ambiente local para o ambiente remoto.

SOAP e RPC
Os RPCs so chamadas remotas de procedimento, que permitem fazer chamadas locais a mtodos de objectos (ou servios) remotos, aceder aos servios de um objecto localizado num outro ponto da rede. Cada chamada ou requisio exige uma resposta. O SOAP foi desenhado para encapsular e transportar chamadas de RPC.

Figura 7 Invocao de um Web Service

Em outras palavras, SOAP possibilita que dois processos comuniquem entre si, independentemente do hardware e da plataforma onde esto a correr Ao utilizar XML para codificar mensagens o SOAP nos d alguns benefcios: XML pode ser facilmente lido pelos utilizadores, portanto, mais fcil de entender e eliminar erros. XML parsers (analistas) e tecnologias correlatas so mundialmente disponveis. XML um padro aberto. XML inclui vrias tecnologias que podem fortalecer o SOAP. Simplificao da especificao, diferente de outros protocolos binrios como COM, DCOM e CORBA. Principais vantagens da utilizao do protocolo SOAP, em relao a outros sistemas de comunicao: Pode atravessar firewalls com facilidade.

 Os dados do SOAP so estruturados usando XML. Portanto, as mensagens podem ser compreendidas por quase todas as plataformas de hardware, sistemas operacionais e linguagens de programao. Pode ser usado, potencialmente, em combinao com vrios protocolos de transporte de dados, como HTTP, SMTP e FTP. O SOAP faz o mapeamento satisfatoriamente para o padro de solicitao / resposta HTTP. Pode ser usado tanto de forma annima como com autenticao bsica (username/password).

Principais desvantagens: Falta de interoperabilidade entre ferramentas de desenvolvimento do SOAP. Embora o SOAP tenha amplo suporte, ainda existem problemas de incompatibilidades entre diferentes implementaes do SOAP. Mecanismos de Segurana Imaturos. O SOAP no define mecanismo para criptografia do contedo de uma mensagem SOAP, o que evitaria que outros tivessem acesso ao contedo da mensagem. No existe garantia quanto entrega da mensagem. Quando uma mensagem estiver sendo transferida, se o sistema falhar, ele no saber como reenviar a mensagem. Um cliente SOAP no pode enviar uma solicitao a vrios servidores, sem enviar a solicitao a todos os servidores.

O facto das aplicaes permitirem que o SOAP seja usado com o HTTP permite transpor barreiras como firewalls com facilidade, permitindo que os softwares que aceitem SOAP estejam disponveis internamente e externamente na rede. Esta caracterstica pode ser vista como vantagem e tambm como desvantagem, j que pode causar um srio problema de segurana, onde as aplicaes do SOAP seriam acessveis por partes no autorizadas. Resumindo, SOAP um protocolo leve, o que faz ele ter poucos recursos e de fcil entendimento. Mas, por outro lado, nos faz ter uma preocupao maior com relao a segurana e transporte das mensagens.

3. Segurana: Solues
Quando falamos de segurana h alguns pontos fundamentais a ter em conta: Autenticao, Autorizao, Confidenciabilidade e a Integridade. Para cada para um deles possvel implementar solues: Autenticao: Quem enviou esta mensagem? Credenciais Login/Password Certificado Digital

Autorizao: O que esta pessoa pode fazer? Usar Roles para definir privilgios

Confidencialidade: Quem pode ler esta mensagem? Encriptao Partilha de chaves secretas ou pares de chaves pblicas/privadas para cifrar e descifrar

Integridade: Algum alterou esta mensagem? Assinatura Digital usada para comparar a mensagem enviada e recebida

WS-* Especificaes
As especificaes dos WS surgem como um meio para tornar standard vrias partes dos Web Services, nomeadamente: Segurana, Polticas, Anexos, Confiana, Descoberta, etc. A parte que interessa a este estudo a que se refere Seguna. Para tal existe o WSSecurity que suporta, integra e unifica vrios modelos, mecanismos e tecnologias de segurana em uso no mercado, permitindo que vrios sistemas possam inter-operar em plataformas e linguagens neutras. Estas especificaes de segurana definem um conjunto de padres para extenses SOAP (Simple Object Access Protocol) ou para cabealhos de mensagens, utilizados para oferecer maior integridade e confidencialidade s aplicaes de Web Services.. O WS-Security oferece os mecanismos-padro de segurana necessrios para realizar o intercmbio seguro de mensagens certificadas, e define como usar encriptao XML e Assinatura XML no SOAP para tornar segura a troca de mensagens, como uma alternativa ou extenso do uso do protocolo HTTPS para tornar seguro o canal num ambiente de Web Services.

Figura 8 - Exemplo de um cenrio com domnios de confiana

WS-Security e o SOAP (Simple Object Access Protocol)

Tal como j foi referido, as credenciais de segurana esto contidas na mensagem SOAP. O WS-Security define o elemento <Security> element, que permite que as security extensions sejam colocadas no <soapenv:header> da mensagem SOAP. Estas podem incluir: Username/password Encryption details XML Signature x.509 certificate Kerberos ticket XrML SAML

Uma mensagem SOAP composta pelos principais elementos apresentados na figura 10.

Figura 9 Mensagem SOAP

Envelope: Toda mensagem SOAP deve conter. o elemento raiz do documento XML. O Envelope pode conter declaraes de namespaces e tambm atributos adicionais como o que define o "encoding style" que indica como os dados so representados no documento XML. Header: um cabealho opcional. Ele carrega informaes adicionais, como por exemplo, se a mensagem deve ser processada por um determinado n intermedirio Body: Este elemento obrigatrio e contm o payload, ou a informao a ser transportada para o seu destino final. O elemento Body pode conter um elemento opcional Fault, usado para carregar mensagens de status e erros retornadas pelos "ns" ao processarem a mensagem.

De seguida podemos ver um exemplo do cdigo de um envelope SOAP, onde especificado no Header a definio e a utilizao do WS-Security namespace.

Estes protocolos so tipicamente implementados no headerSOAP!

3.3.1 Security Tokens para o elemento <Security>

O modelo base de servios seguros foi proposto inicialmente pela IBM e Microsoft e faz actualmente parte da norma OASIS. O modelo descreve a forma como se processam as invocaes que se pretendem seguras. Cada servio tem uma poltica que define as condies de acesso e os tokens de segurana exigidos. Por exemplo, um servio pode exigir que uma mensagem que recebe seja cifrada e que contenha um token com utilizador e senha. Se a mensagem chegar sem provas suficientes, o servio pode ignorar ou rejeitar a mensagem. A figura 10 ilustra o modelo de servios seguros. As setas representam comunicao entre extremidades de servios.

Figura 10 - Modelo de base para Web Services seguros.

Um token , literalmente, um smbolo. Para os Web Services um Token uma reivindicao qualquer que geralmente representa a identificao do utilizador. Trata-se de uma declarao feita por uma entidade, como nome, identidade, chave grupo, privilgio, capacidade, etc. O username um exemplo de um unsigned security token. Com o WSE possvel adicionar estes tokens mensagem SOAP e verificar, em qualquer um dos lados, a validade dele. O exemplo abaixo gera um token e adiciona classe proxy do Web Service. Antes preciso importar o namespace necessrio: (C#) using Microsoft.Web.Services2.Security.Tokens; UsernameToken token = new UsernameToken( "admin", "admin", PasswordOption.SendPlainText ); Service1.RequestSoapContext.Security.Tokens.Add(token); Service1.RequestSoapContext.Security.Elements.Add(new MessageSignature(token)); Um Signed Security Token criptograficament assinado por uma autoridade especfica, como um X.509 certificate ou um Kerberos ticket. Este elemento pode ser usado para providenciar um user name no <wsse:Security>, para Basic Authentication.

Figura 11 - < wsse:Security>, para Basic Authentication

Os Signed security tokens, como o Kerberos ticket ou x.509 certificate, so de contedo binrio. Devem ser codificados para serem incluidos no wsse:Security container

Figura 12 - O WS-Security elemento <BinarySecurityToken>

3.3.2 Encriptao XML

O standard de encriptao XML define a forma de cifrar todo um documento XML ou apenas partes. A informao cifrada substituda por um nico elemento <EncryptedData>. Pode-se cifrar diferentes partes do mesmo documento com diferentes chaves, ou ento, podese cifrar todo o documento, um nico elemento, ou apenas o texto de um elemento <PayBalanceDue xmlns='http://example.org/paymentv2'> <Name>John Smith<Name/> <CreditCard Limit='5,000' Currency='USD'> <Number>4019 2445 0277 5567</Number> <Issuer>Bank of the Internet</Issuer> <Expiration>04/02</Expiration> </CreditCard> </PayBalanceDue > <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' Type='http://www.isi.edu/in-notes/iana/assignments/media- types/text/xml'> <CipherData><CipherValue>A23B4C6</CipherValue></CipherData> </EncryptedData> A identidade do elemento de pagamento est escondida no form de encriptao. No possvel ver nem o tipo de transaco que ! No exemplo seguinte, o nmero <Number> encriptado, mantendo-se os restantes elementos visveis. <PayBalanceDue xmlns='http://example.org/paymentv2'> <Name>John Smith<Name/> <CreditCard Limit='5,000' Currency='USD'> <Number>4018 2445 0277 5567</Number>

<Issuer>Bank of the Internet</Issuer> <Expiration>04/02</Expiration> </CreditCard> </PayBalanceDue > O nmero substituido pelo EncryptedData element: <PayBalanceDue xmlns='http://example.org/paymentv2'> <Name>John Smith<Name/> <CreditCard Limit='5,000' Currency='USD'> <Number> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' Type='http://www.isi.edu/in-notes/iana/assignments/mediatypes/text/xml'> <CipherData><CipherValue>A23B4C6</CipherValue></CipherData> </EncryptedData> </Number> <Issuer>Bank of the Internet</Issuer> <Expiration>04/02</Expiration> </CreditCard> </PayBalanceDue >

A XML-Signature e XML-Encryption so duas normas que definem como assinar e cifrar documentos XML, respectivamente. Ambas podem ser aplicadas selectivamente a partes da mensagem ou a contedos externos referenciados nos documentos. A diferena mais notria entre ambas que elemento de assinatura (Signature) referencia o que est a ser assinado enquanto que o elemento de dados cifrados (EncryptedData) contm o que est a ser cifrado. A WS-Security permite proteger a mensagem SOAP e transportar tokens de segurana, definindo o modelo base de segurana descrito anteriormente. A WS-Security permite as seguintes operaes sobre a mensagem SOAP: Acrescentar data e identificao mensagem; Enviar tokens de segurana no cabealho; Usar XML-Signature para assinar toda ou parte da mensagem e enviar a assinatura no cabealho; Usar XML-Encryption para cifrar toda ou parte da mensagem; Enviar chaves criptogrficas ou referncias no cabealho. Estas operaes so descritas pelos seguintes elementos: O elemento <EncryptedData> substitui o contedo a ser cifrado, e este contm: <EncryptionMethod> Algoritmo usado para cifrar os dados <CipherData> <CipherValue> contm os dados encriptados

<EncryptedKey> elemento do security header, contm: <EncryptionMethod> Algortitmo usado para cifrar a chave simtrica <KeyInfo> Identificado da chave usado para cifrar a a chave simtrica <CipherData> <CipherValue> Chave simtrica cifrada <ReferenceList> Lista de <DataReference>s encriptados com a chave

Figura 13- Exemplo: Assinatura XML (no SOAP)

4. .NET Web Services e WSE

Apesar de os Web Services serem independentes da plataforma, refere-se aqui a plataforma .NET por ter suporte para todos os protocolos referidos. O ASMX a implementao de Web Services para o .NET FrameWork, e este suporta uma segurana bsica para servios simples, mas no implementa especificaes WS-*. Para tal existe o WSE que uma extenso do .NET FrameWork, e extende as funcionalidades dos Web Services, provendo suporte para diversas especificaes WS-*.

Figura 14 - WS-Security framework

A WS-SecurityPolicy uma especializao da WS-Policy para definir polticas de segurana que descrevem a forma como as mensagens devem ser tornadas seguras. A poltica pode aplicar-se a mensagens individuais, a operaes ou a toda a extremidade do servio. As asseres WS-SecurityPolicy referem-se s funcionalidades de segurana de WS-Security, WS-Trust e WS-SecureConversation. Podem tambm referir segurana no transporte, como HTTPS. Cada cenrio representado por um tipo de segurana, como apresentado na Figura 15.

Figura 15 Policies Assertions

As asseres de tokens de segurana identificam quais so os tokens aceites e qual o processamento que lhes deve ser dado. Os tokens podem ser: HttpsToken, UsernameToken, X509Token, KerberosToken, SamlToken e RelToken. Por exemplo, o token HttpsToken indica o uso de HTTPS, podendo tambm especificar se o certificado cliente obrigatrio. As asseres permitem expressar autenticao, atributos e autorizao de agentes com identidade num domnio de segurana.

WS-Trust
A WS-Trust define um modelo de confiana com operaes para adquirir, emitir, renovar e validar tokens de segurana e formas de criar novas relaes de confiana atravs de servios intermedirios. Define: O security token service Uma autoridade de confiana para security tokens implementados como um Web service As mensagens SOAP so enviadas para este servio para emisso de security token, validao e troca

Figura 16 WS-Trust

WS-Federation
A WS-Federation define federaes de servios para partilhar informao sobre identidade, atributos, autenticao e autorizao entre diferentes domnios de confiana. Construido sobre o modelo WS-Trust Define mecanismos para troca de security tokens entre domnios de confiana No requer a identidade local nos servios destino Opcionalmente permite esconder a informao da identidade e de outros atributos.

Figura 17 WS-Federation

WS-Secure Conversation
A WS-SecureConversation permite que dois servios estabeleam uma sesso segura entre si para trocarem vrias mensagens. Assim, possvel tirar partido de segredos partilhados para derivar chaves simtricas de sesso e ter segurana de forma mais eficiente e robusta. Define os mecanismos para estabelecer e partilhar contextos de segurana e derivar chaves de sesso dos contextos de segurana. Existem 3 formas de estabelecer o contexto de segurana: Security context token criado pelo security token service Security context token criado por uma das partes da comunicao e propagado com a mensagem Security context token criado atravs de negociao

Figura 18 - Exemplo SecurityContextToken

WS-Privacy
O WS-Privacy define as polticas para a forma como o service provider ir usar a informao fornecida pelo service requester. um modelo de como os utilizadores definem as suas preferncias de privacidade, e como os os web services implementam as prticas de privacidade. As preferncias so especificadas sob a forma de policy assertions no WSPolicy container.

WS-Authorization
O WS-Authorization decreve como as politicas de acesso ao Web Service so especificadas e geridas. Descreve com os pedidos podem ser especificados com security tokens, e como sero interpretados no final.

A Figura 19 apresenta algumas solues existentes no mercado para a implementao de Web Services seguros, em vrias plataformas.

Figura 19 - Normas suportadas nas principais implementaes de servios seguros.

5 . Exemplo de um Web Service

calculadora.asmx
<!--Define que um WebService, o tipo de linguagem e o nome da classe--> <%@ WebService language="C#" class="Calculadora" %> using System; //Inclui as classes que so necessrias para um WebService using System.Web.Services; using System.Xml.Serialization; //Define que o nome da classe public class Calculadora { //O que torna um metodo de um classe pblico para ser invocado a tag //[WebMethod todas os mtodos que tiverem esta tag sero pblicos. [WebMethod] //Metodo que recebe dois inteiros os soma e retornar um tipo int public int Add(int a, int b) { return a + b; } catch { return 0; } }}

Acede-se a um web service a partir de uma aplicao,criando uma web service proxy class. Depois usa-se a ferramenta de linha de comandos Wsdl.exe . A proxy class funciona como um intermedirio entre o servidor de web service e o cliente de web service. A proxy class camufla toda a complexidade da chamada de um web service. O utilizador no precisa de saber SOAP, onde o web service reside e nem precisa de saber lidar com a mensagem de XML.

Concluso
A implementao de mecanismos de seguranas em ambientes Web em que so partilhados servio entre domnios de confiana fundamental. As plataformas que implementam os Web Services j so dotadas de pacotes, como o WSE do .NET, que apresentam solues prticas e funcionais para a maioria destes problemas. A configurao do WSE auxiliada por wizards o que torna o processo para o utilizador bem mais fcil e transparente. As principais reas de actuao do WSE incluem a possibilidade de envio de arquivos anexos, a incluso de tokens e assinaturas digitais, e, por fim, a utilizao de uma poltica de segurana. Para aplicaes mais cruciais aconselhvel uma segurana mais robusta, utilizando as polticas que envolvem certificados X.509, Secure Conversations ou KerberosTokens.

Referncias Bibliogrficas
1. Kaler, C. & Nadalin, A., Web Services Security Policy Language (WS-SecurityPolicy) Version 1.1, Microsoft, IBM, VeriSign, RSA Security, 2005 2. Anthony Nadalin, C.K., Web Services Security: SOAP Message Security 1.0 (WSSecurity 2004), OASIS, 2004 3. Hogg, J.; Smith, D.; Chong, F.; Taylor, D.; Wall, L. & Slater, P., Web Service Security Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0, Microsoft, 2005 4. IBM & Microsoft, Security in a Web Services World: A Proposed Architecture and Roadmap Version 1.0, IBM, Microsoft, 2002 5. Microsoft, Microsoft Web Services Enhancements (WSE) 3.0 documentation, 2005 http://msdn.microsoft.com/webservices/webservices/building/wse/default.aspx 40.