Recommended way to insert wsse:UsernameToken in SOAP header

[barnett.w]

Hi,

I'm currently evaluating SmartGWT for purchase in the near future, and a very important capability I'm interested in is the WSDL Binding capability. This question is generic and isn't specific to any code sample, SmartGWT version or WSDL.

I'm dealing with a WSDL for a third party web service, where I don't have access to make changes to the schema. In order to authenticate with the web service, each SOAP request needs to include the following header:

<soapenv:Header>
   <wsse:Security mustUnderstand="1">
      <wsse:UsernameToken wsu:Id="Example-1">
         <wsse:Username> ... </wsse:Username>
         <wsse:Password Type="..."> ... </wsse:Password>
         <wsse:Nonce EncodingType="..."> ... </wsse:Nonce>
         <wsu:Created> ... </wsu:Created>
      </wsse:UsernameToken>
   </wsse:Security>
</soapenv:Header>

My understanding is that this is a fairly standard WSSE security header. It's standard enough that it isn't explicitly defined in the WSDL schema.

If I were to use SOAP-UI, the instructions to perform this operation are specified here: http://www.soapui.org/soap-and-wsdl/authenticating-soap-requests.html. By simply setting, the username, password and 'WSS-Password Type' field to "PasswordText" SOAP-UI is intelligent enough to generate and use the header automatically.

Digging through the Javadoc, I'd assume that the header could be set using:

WSRequest.setHeaderData()

Since the WSDL doesn't define this header, and it isn't defined in a physical xsd file, adding a username field to the header data will yield the following response:

headerData passed for SOAP header partName: Username, no schema available, not outputting

Failing to enter the header in the SOAP message yields an error (summarized):

<faultstring>Security Requirements not met - No Security header in message</faultstring>

I've looked at the Salesforce example hiding in the Smartclient zip file, and it doesn't provide the information I need. It uses a very specific login, log off capability clearly defined in the WSDL, and my WSDL uses a more generic authentication. Also, I am trying to evaluate SmartGWT and not SmartClient, so a Java based solution would be better.

Does SmartGWT provide a way to specify this SOAP-UI style of authentication header (knowing that it is not explicitly defined in the WSDL)? In the worst case, I would fine entering manual text as the header section rather than using the xml serialization.

I think this question is generic enough across multiple projects and WSDLs.
What is the recommended way to authenticate SOAP requests with SmartGWT?

[Isomorphic]

We don't have a specific recommendation for how to authenticate SOAP requests, because it's useless to offer such a recommendation - you have to integrate with whatever is there.

We support the usual ways: cookies, other HTTP headers, WSDL headers.

It looks like your situation is a bit of a mess - a WSDL service *should* be telling you if WSSE tags are allowed in the header, and if it doesn't say they are allowed, it should reject a message that contains them!

As far as hacking around this problem, you can acquire the SOAP message that conforms to the WSDL via WebService.getSoapMessage(), then splice in hand-formed WSSE headers yourself, and send the message using the RPCManager layer.

[barnett.w]

Thanks for your quick reply. I'll give the "hacking" solution a try.

You might be interested in the following article from the Organization for the Advancement of Structured Information Standards (OASIS) who produced the WSSE standard: http://docs.oasis-open.org/ws-sx/security-policy/examples/ws-sp-usecases-examples.html"

In particular, section 2.1.1.1 UsernameToken with plain text password:

This scenario is based on the first WS-Security Interop Scenarios Document [WSS10-INTEROP-01 Scenario 1 – section 3.4.4]

(http://www.oasis-open.org/committees/download.php/11374/wss-interop1-draft-06-merged-changes.pdf).

This policy says that Requestor/Initiator must send a password in a UsernameToken in a WS-Security header to the Recipient (who as the Authority will validate the password). The password is required because that is the default requirement for the Web Services Security Username Token Profile 1.x [WSS10-USERNAME, WSS11-USERNAME].

This setup is only recommended where confidentiality of the password is not an issue, such as a pre-production test scenario with dummy passwords, which might be used to establish that the Initiator can read the policy and prepare the message correctly, and that connectivity and login to the service can be performed.

(P001)     <wsp:Policy>
(P002)       <sp:SupportingTokens>
(P003)         <wsp:Policy>
(P004)           <sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient"
(P005)         </wsp:Policy>
(P006)       </sp:SupportingTokens>
(P007)     </wsp:Policy>

An example of a message that conforms to the above stated policy is as follows.

(M001)          <?xml version="1.0" encoding="utf-8" ?>
(M002)          <soap:Envelope xmlns:soap="...">
(M003)            <soap:Header>
(M004)              <wsse:Security soap:mustUnderstand=“1” xmlns:wsse="...">
(M005)                <wsse:UsernameToken>
(M006)                  <wsse:Username>Chris</wsse:Username>
(M007)                  <wsse:Password Type=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText”>sirhC</wsse:Password>
(M008)                  <wsse:Nonce EncodingType="...#Base64Binary"
(M009)                     >pN...=</wsse:Nonce>
(M010)                  <wsu:Created>2007-03-28T18:42:03Z</wsu:Created>
(M011)                </wsse:UsernameToken>
(M012)              </wsse:Security>
(M013)            </soap:Header>
(M014)            <soap:Body>
(M015)              <Ping xmlns="http://xmlsoap.org/Ping">
(M016)                <text>EchoString</text>
(M017)              </Ping>
(M018)            </soap:Body>
(M019)     </soap:Envelope>

The UsernameToken element starting on line (M005) satisfies the UsernameToken assertion on line (P004). By default, a Password element is included in the UsernameToken on line (M007) holding a plain text password. Lines (M008-M010) contain an optional Nonce element and Created timestamp, which, while optional, are recommended to improve security of requests against replay and other attacks [WSS10‑USERNAME]. All WS-Security compliant implementations should support the UsernameToken with cleartext password with or without the Nonce and Created elements.

The WSDL I'm looking into does in fact specify lines (P001-P007), which is why it works with SOAP-UI.

[Isomorphic]

Hmm, this seems, at first read, as though OASIS grafted something onto WSDL which actually contradicts WSDL's strict rules about having to declare message formats formally.

Then again, the reality of WSDL is that most implementations violate the spec in one way or another and implementations just have to hack around this..

Either way, we'll keep an eye out for whether this requirement comes up again - the spec you quoted suggests that this would be an uncommonly used approach - and if you want to be sure of having WSSE in the framework by a particular date, consider Feature Sponsorship.