Segurança em Web Service Rest x SOAP?

6 respostas
C

Oi gente,

temos que construir um web service para ser acessado por uma empresa cliente, não temos experiência com isso e precisamos como requisito principal focar na segurança.

Fiz muitas pesquisas de vantagens e desvantagens Rest x SOAP.

A princípio um fator está nós levando a utilizar SOAP, o fato de possuir um padrão de segurança denominado web service security, tal qual REST não possui.

Analisando o requisito principal “segurança”, podemos concluir que utilizar SOAP teremos mais segurança do que REST?

Obrigada a todos.

6 Respostas

A

carol_programadora:
Oi gente,

temos que construir um web service para ser acessado por uma empresa cliente, não temos experiência com isso e precisamos como requisito principal focar na segurança.

Fiz muitas pesquisas de vantagens e desvantagens Rest x SOAP.

A princípio um fator está nós levando a utilizar SOAP, o fato de possuir um padrão de segurança denominado web service security, tal qual REST não possui.

Analisando o requisito principal “segurança”, podemos concluir que utilizar SOAP teremos mais segurança do que REST?

Obrigada a todos.

REST possui segurança baseada em HTTP. Isso quer dizer que existem várias formas possíveis de autenticação via REST, sendo as principais BASIC e DIGEST. SOAP também pode fazer uso dessas formas, desde que seja baseado em HTTP (SOAP não foi criado para ser utilizado somente sobre protocolo HTTP).

O que deve ser levado em consideração na escolha de um ou outro não são os requisitos não-funcionais, mas sim, a filosofia: REST funciona com recursos. Isso quer dizer que a aplicação deve (ou deveria) ser modelada como recursos. SOAP já segue uma abordagem mais tradicional, baseada em RPC, o que faz com que a modelagem da aplicação em si seja mais simplificada. Em contrapartida, a publicação e consumo de web services baseados em SOAP e WSDL são mais burocráticas, em contrapartida ao REST, que possui um modelo mais simplificado por esse ponto de vista.

Em resumo: segurança pode ser feita tão bem em um quanto o outro. Mas cuidado com uma decisão baseada apenas por esses pontos de vista, OK?

[]'s

W

Dá uma olhada em JAX-WS ele dá suporte a SOAP e é bem tranquilo de implementar.

Dá uma olhada nesse site: http://www.devmedia.com.br/desenvolvendo-web-services-utilizando-jax-ws/2374

G

Você pode implementar a segurança em WebServices de várias formas, pois o WebService vai trafegar XML sem criptografia alguma, portanto pode ser interceptado e interpretado

Se você utilizar o HTTPS na comunicação entre os sistemas vai incrementar o nível de segurança, desta forma você garante a segurança na internet/intranet porém permite que qualquer sistema conecte ou seja não é uma implementação na camada do WebServices e sim em uma camada externa a comunicação,

Para evitar de que qualquer sistema conecte você pode criar um método de autenticação que recebe usuário e senha e retorna um token criptografado validado, e esse token será usado em todas as outras requisições de métodos do webservice.

Se não existir o token ou ele restar inválido você não deixa conectar.

Essa camada de segurança você pode delegar para um application server como Websphere por exemplo http://www.ibm.com/developerworks/websphere/tutorials/0905_griffith/

F

Se a segurança for no transporte, acredito que SOAP (sobre HTTP) e REST são a mesma coisa.
Sugiro usar HTTPS e uma autenticação digest ou basic.

P

Pelo que vc. descreveu do seu cenário (conversar com um cliente), eu iria de SOAP + WS-Security. Motivos básicos:

  • SOAP é, ao menos no que diz respeito à estrutura da informação que será trafegada, auto-documentado. O WSDL associado ao serviço é um contrato formal e, de modo geral, a interoperabilidade é uma realidade e conta com ferramental de desenvolvimento para as principais linguagens de mercado.

  • O WS-Security é capaz de garantir a segurança (em particular, as propriedades de confidencialidade e autenticidade) da mensagem em todo o trajeto a mensagem, e não apenas durante a transmissão dos dados, como é o caso da segurança de transporte proporcionada pelo HTTPs.

Adicionalmente, sugiro não expor diretamente os servidores que contém a implementação do serviço para o mundo externo. Considere no mínimo um proxy reverso na entrada ou, se quiser olhar uma alternativa mais completa, dê uma olhada nas alternativas de ESB free disponíveis. O meu preferido para este tipo de cenário é o WSO2 ESB pois é possível ativar/desativar a segurança em ambiente de produção apenas mudando a configuração do endpoint via interface administrativa.

R

http://www.teses.usp.br/teses/disponiveis/55/55134/tde-24072012-164751/pt-br.php

Criado 16 de março de 2012
Ultima resposta 26 de jul. de 2012
Respostas 6
Participantes 7