Diferença entre o cabeçalho SOAP security e o SOAP header

Qual é a diferença entre o cabeçalho de segurança SOAP (wsse) e o cabeçalho geral SOAP? E se eu usar soap headers simples para enviar as minhas credenciais?

Porque devo usar isto: 

<soapenv:Header>
  <wsse:Security  xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
     <wsse:UsernameToken wsu:Id="UsernameToken-1">
        <wsse:Username>login</wsse:Username>
        <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">XXXX</wsse:Password>
     </wsse:UsernameToken>
  </wsse:Security>

e não deve usar isto: 

<S:Header>
    <Username xmlns="http://ws.enterprise.com/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:actor="http://schemas.xmlsoap.org/soap/actor/next">
        Username text
    </Username>
</S:Header>
Obrigado antecipadamente!

Author: 0bj3ct, 2016-05-12
Source

1 answers

Ambos responderiam à necessidade funcional de passar um nome de utilizador e uma senha.

Ambos são igualmente simples.

Um é uma norma aberta (na verdade, uma pequena num conjunto de normas bem pensadas para as necessidades de segurança das mensagens de sabão extremo-a-extremo, que vão desde autenticação, confidencialidade das mensagens, não repúdio, etc.). O outro é específico para a sua aplicação; proprietário, mas pode ser tudo que você precisa.

As vantagens possíveis da utilização Ws-segurança:
  • já está documentado (menos trabalho para ti. Basta documentar que você usa WS-Security UsernameToken e os clientes podem Google {[8] } o resto)
  • já implementado (menos trabalho para os seus consumidores, possivelmente até para a implementação do seu serviço web). Muitos frameworks de biblioteca (Java: Apache wss4j, Apache CXF, JavaScript: Node.js , Python: suds ), Servidores de aplicações JavaEE tais como IBM WebSphere , Oracle WebLogic , RedHat JBoss AS, e outras plataformas empresariais tais como . Net - todos têm técnicas pré-construídas, em muitos casos de configuração-apenas técnicas para garantir serviços web com esta norma aberta específica (WS-Security UsernameToken).
    • Espaço para crescer. Este é apenas um dos muitos padrões relacionados . Deseja / precisa de autenticar alguns clientes através do utilizador/senha, mas outros através da assinatura digital? Há um padrão relacionado lá. Não teria de o fazer. invente um, que inclui não só a sintaxe XML necessária, mas também pensar através de vários vetores de ataque. Os padrões abertos já tiveram muitos olhos examinando-os.

Possíveis desvantagens:

  • curva de aprendizagem : escolher usar material pré-construído significa que você (e o seu cliente) têm de o compreender até certo ponto.
  • exagero para alguns casos extremos . Estou a alongar-me um pouco. Digamos que isto é um protótipo de serviço web, nunca programado para uso comercial ou de produção. Construir um serviço web e exactamente um cliente de serviço web? Código descartável, não queres deixar "aberto" por um período de tempo? Força.
 2
Author: Scott Heaberlin, 2016-05-17 01:40:33