Unterschied zwischen SOAP-Sicherheitsheader und SOAP-Header

Question

Was ist der Unterschied zwischen SOAP-Sicherheitsheader (WSSE) und allgemeinem SOAP-Header? Was ist, wenn ich nur einfache Soap-Header zum Senden meiner Anmeldedaten verwende?

Warum soll ich verwenden:

<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> 

Und sollte dies nicht verwenden:

<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> 

Vielen Dank im Voraus!

Answer 1

Beide würden die funktionelle Notwendigkeit erfüllen, einen Benutzernamen und ein Passwort zu übergeben.

Beide sind gleichermaßen einfach.

Eines ist ein open standard (eigentlich ein kleines in a set von durchdachten Standards für End-to-End-SOAP-Nachrichtensicherheitsanforderungen, die von Authentifizierung, Vertraulichkeit der Nachricht, Nichtabstreitbarkeit usw. reichen). Der andere ist spezifisch für Ihre Anwendung; proprietär, aber könnte alles sein, was Sie brauchen.

Mögliche Vorteile der Verwendung von WS-Security:

• Bereits Dokumentierte (. Weniger Arbeit für Sie dokumentieren Nur Sie WS-Security UsernameToken und Kunden verwenden können, um den Rest Google)
• bereits umgesetzt (weniger Arbeit für Ihre Kunden, möglicherweise sogar für Ihre Web-Service-Implementierung). Viele Bibliothek Frameworks (Java: Apache WSS4J, Apache CXF, JavaScript: Node.js, Python: suds), JavaEE Applikationsserver wie IBM WebSphere, Oracle WebLogic, RedHat JBoss AS und andere Unternehmensplattformen wie .NET - alle haben vorgefertigte, in vielen Fällen nur Konfigurations-Techniken zur Sicherung von Web-Services mit diesem bestimmten offenen Standard (WS-Security UsernameToken).
• Raum zum Wachsen. Dies ist nur einer von many related standards. Möchten/müssen Sie einige Kunden mit Benutzername/Passwort authentifizieren, andere jedoch mit digitaler Signatur? Da gibt es einen verwandten Standard. Wäre es nicht nötig, einen zu erfinden, der nicht nur die benötigte XML-Syntax beinhaltet, sondern auch verschiedene Angriffsvektoren durchdenkt. Die offenen Standards haben bereits viele Augen gehabt, die sie überprüft haben.

Mögliche Nachteile:

• Lernkurve: Auswahl vorgefertigtes Material zu verwenden, bedeuten, dass Sie (und Ihr Client) es zu einem gewissen Grad zu verstehen haben.
• Overkill für einige Randfälle. Ich dehne mich ein bisschen hier. Nehmen wir an, es handelt sich um einen Prototyp-Webdienst, der niemals für den geschäftlichen oder produktiven Einsatz vorgesehen ist. Einen Web Service und genau einen Web Service Client erstellen? Wegwerf-Code, den Sie einfach nicht "weit offen" für eine gewisse Zeit verlassen möchten? Tue es.