CODEWITHSUNDEEP
xmlweb-servicessoapjax-ws
0bj3ct
0bj3ct

Reputation: 1490

Difference between SOAP security header and SOAP header

What is the difference between SOAP security header (WSSE) and general SOAP header? What if I use just simple soap headers for sending my credentials?

Why I should use this:

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

And should not use this:

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

Thanks in advance!

Upvotes: 2

Views: 12554

Answers (1)

Scott Heaberlin
Scott Heaberlin

Reputation: 3424

Both would meet the functional need of passing a username and password.

Both are equally simple.

One is an open standard (actually one small one in a set of well-thought out standards for end-to-end SOAP message security needs, ranging from authentication, message confidentiality, non-repudiation, etc). The other is specific to your application; proprietary, but might be all you need.

Possible advantages of using WS-Security:

  • Already Documented (less work for you. Just document you use WS-Security UsernameToken and clients can Google the rest)
  • Already Implemented (less work for your consumers, possibly even for your web service implementation). Lots of library frameworks (Java: Apache WSS4J, Apache CXF, JavaScript: Node.js, Python: suds), JavaEE app servers such as IBM WebSphere, Oracle WebLogic, RedHat JBoss AS, and other enterprise platforms such as .NET - all have pre-built, in many cases configuration-only techniques for securing web services with this particular open standard (WS-Security UsernameToken).
  • Room to grow. This is just one of many related standards. Want/need to authenticate some clients via username/password, but others via digital signature? There's a related standard there. Wouldn't have to invent one, which includes not only the XML syntax required, but also thinking through various attack vectors. The open standards have already had many eyes vetting them.

Possible disadvantages:

  • Learning curve: Choosing to use pre-built stuff means you (and your client) have to understand it to some extent.
  • Overkill for some edge cases. I'm stretching a bit here. Let's say this is a prototype web service, never slated for business or production use. Building one web service and exactly one web service client? Throwaway code you just don't want to leave "wide open" for a period of time? Go for it.

Upvotes: 4

Related Questions