I am looking for information on how to implement WS-Security in IS 7.1. I came across many older postings and wonder if there is any support in 7.1. Have not found anything in either the documentation or on the advantage web site. I would be grateful for just getting pointed in the right direction. I did glance over Marks Blog, but am hoping that is dated as far as webMethods goes (no offense Mark).
IS versions 7.1 and later support WS-Security out-of-the-box by configuring a “provider” web services descriptor node. See Chapter 5 in the updated Web Services Developer’s Guide available on Advantage and be sure to request the new WmSOAPSamples package which shows how to configure a few WS-Security scenarios as well as how to create a JAX-RPC handler to deal with a simple custom header requirement. This package is not available on Advantage as of Feb 18, 2008.
Thanks for the response! I will be following up the information. A quick question - Does it matter whether the webservice is a consumer? What I need to do is pass the Security tag and relevant elements to a customers web service where security is a requirement.
Ok. I have read and re-read the documents and they were quite helpful. I think I have set everything up right. The problem is that it still does not work.
Attached is a dump of the soap request as well as the policy file I have associated with the web service descriptor. I think that the problem is that the web service I am trying to consume is not expecting a timestamp node. I have removed it from the policy file but it still gets inserted. Aside from the policy file, is there a way to explicitly determine which nodes are being inserted?
At the risk of looking like a complete dufus I need to ask the following question. When using WS-Security is communication between client and server a 2 step communication? By that I mean does the soap header which contains the UsernameToken work as a handshake mechanism whereby the soap body is not sent until the header has been “authorizied”. The reason I ask is that all my soap requests contain and empty soap body (see previous post) - even though within webMethods I am populating the request object. At least, I believe I am based on the results window. But the soap request dump makes me think otherwise.
The second question I have is about tcpTrace. Does it support https for the destination server? webMethods just hangs whenever I use the actual remote server address. Becuase of this I have been using localhost in order to get the soap request message.
No two-step handshake. Once the HTTP/S connection is established, the entire SOAP request is posted to the service provider’s server. Typically WS-Security tokens are processed at the container-level and only if valid is the request passed to the service implementation.
Suggest getting this working over HTTP first, then moving to HTTPS.
Empty soap body elements suggest an issue in the Flow service consuming the service.
Hmmm. That didn’t appear to be covered in the Web Services Developer’s Guide. Sounds like a good question for WM support though.
What is driving the namespace requirement. Pretty sure the namespaces WM is using are based on the WS-Security 1.0 spec. Refer to section 2.2 - Namespaces. The 2003/06 version you are attempting to use would appear to be pre-WS-S 1.0 and not well-supported by most platorms.
Unfortunately, the publisher of the web service I am attempting to consume is driving the requirement. They only accept 3 possible variants. And none of them are the ones that webMethods uses. I agree they seem a bit dated…
Below is part of the soap fault returned. The namespace inserted is what is expected.
You may have to code your own Flow to construct the desired (non-standard) flavor of WS-Security token by adding a header to an empty soap message.
This was the only option in IS versions prior to 7.1.1 and works quite well so long as you can build an IS doc type to hold the basic token structure and then use the desired namespaces in your pub.xml:documentToXMLString call by populating the nsDecl parameter.
Are there any more detailed error messages in the error log or server log? What type of security token are you using? It appears that you are sending a UsernameToken, but that the security policy you have selected is expecting another type of token or no token at all.