I’m trying to get webMethods v9.5 to fill in the wsse:security tag in the soap header with an encrypted block for a connector (outbound soap request). I’m using a web service alias that is configured and I’ve attached a policy to the descriptor but I can’t seem to be able to attach a handler - is there anything out of the box that will generate the security tag in the soap header?
Any help on how to add the wsse:security tag to the soap header for outbound requests?
Thanks in advance,
I was exactly in same boat as you until two weeks ago and i can tell from first hand that you can do this with Java*.
I put an astrik up there because it will work in a J2EE environment but unfortunately the same jars(rampart libraries) are used by webMethods internally(some wrapper classes) and when you import the external java program in to webMethods you will get a jar conflict and can not resolve them.
As far as i know SAG does not provide anything out of the box to generate this content(WS Security header) and i have ticket to prove that . My suggestion would be use a policy file to generate this content.
Another option if you have CS-Mediator is to apply a security policy matching your requirements on a virtual service and that will generate a policy file in the Virtualized WSDL. You can copy paste this policy information in to a file and then use it on the WSD in webMethods. Of course this is doing things backwards but will get your job done.
By default the policy will be applied to input,output and fault on the WSD. If you want this policy to take affect only for outgoing soap request then just apply it on the input.
Thanks. I’m using v9.5 and set the policy on the descriptor along with a handler (wm provides a series of policies) but it’s not generating the security tag based on the server log output.
Can you explain how to get the security tag in the soap request? Did you write code or create y our own policy files etc. It shouldn’t be this hard, I already set up the web service alias with the certificate info.
This should be supported by WM without any customer coding.
If you are connecting to a non-WM based system, turn off the: pre-8.2 compatible mode.
Create a WS client alias.
Assign the alias to the WS descriptor’s binder
Assign a policy (X509Authentication_Signature_Encryption).
you should be able to generate request with wsse:Security header.
Thanks. That’s how I think it should work too. When assigning a policy in 9.5 I get a warning about no handler for WsHeaderIn which is in the wsdl for the security tag, but when I run the consumer the server logs don’t show any security info in the header. I assume the logs would show that on the way out.
I also get this error now from the external partner but the logs don’t show any header populated (assuming it’s logged right at the end before sending to partner).
Method ‘xenc:EncryptedData’ not implemented: method name or namespace not recognized
The server logs will not show the payload with the WSSE headers added as the policy file that you applied will take affect after writing to the logs(they need to fix this). If the required WSSE header is missing after you apply the policy then you will be getting “Missing soap header” error from Axis jars in webMethods.
In my case i did not use the 8.2 pre-compatibility mode i just applied the policy file and that added the WSSE headers to the SOAP payload but i had to contact our partner(Datapower) to get logs from their end to see the exact payload.
webMethods can not capture this out of the box, you have to setup TCPMON(proxy the call) to do that.
I opened a feature request(01994) with SAG when they closed the support ticket about this. Hopefully they will address this issue shortly as there is lot of room for improvement in this area.
IMHO using the 8.2 pre-compatibility mode is redundant starting 9.6. Of course that is just my personal opinion.
Are you implementing encryption as well? Looks like the payload is coming back with some “EncryptedData” elements but the WS Policy that you are using might not have this defined in it. You need to encrypt the message after signing in the policy.
Thanks for your help. That seems to appear when I uncheck the fault box so when that is checked I get org.apache.axis2.AxisFault: SOAP header missing, from the server side. Also when saving the policy I get ‘no handler for WsHeaderIn’. WsHeaderIn is declared in the WSDL (see below), is there a way to map that to the security header elements generated by webMethods?
<soap:header message=“tns:WsHeaderIn” part=“Security” use=“literal” />
Looks like the fault that the server is sending back does not have the security headers in it so you can keep it unchecked.
Is your policy passing the IS validation? If it failed IS will move the policy file in to invalid directory i think.
I am not sure if you can map the WSDL field in to the security headers using webMethods. My guess is you can not.
I’m using the built in policies that show up in the drop down (x509 authentication, signature and encryption). Should I be writing my own policy file? I thought we could use the ones wm provides. And what should I do about the WsHeaderIn error message and xenc:ecnryption error message?
Sorry, i was under the impression that you were writing a custom policy that is going to meet a security requirement not covered by IS.
WsHeaderIn error message
Are you using pre-compatability mode? If you are using the policy(WSSE headers) then why do you still need a handler?
You mentioned that this happens only when you check the fault checkbox as well right? keep it unchecked, looks like the server fault being sent back to webMethods does not have the security headers but IS is still applying the policy on fault(default), which it should not.
No pre mode, just wm 9.5. There’s no handler i just choose a plicy and that error pops up, probably because it’s declared in the WSDL snippet I provided in the last post. there’s a WsHeaderIn document type in the connector as well. Just want this to work so any tips would be appreciated. I get different errors if I uncheck the in/out/fault boxes. like missing security header, xenc: encryption method not found, and signature/decryption invalid, Referenced security token could not be retrieved.
At this point i am suspecting that the out of box policy might not work for your security requirement. Can you post a SOAP request\response here or add as an attachment. I will be able to tell for sure if the out of the box policy from webMethods will work in this scenario. You are using the X509Authentication_Signature_Encryption.policy?
Yes I’m using that one and I’ve tried others. I’ve attached the wsdl as well as a sample soap message that I’m trying to replicate. Thanks for your help I realy appreciate it.
XiSecureWS.wsdl (7.65 KB)
sampleSoapRequest.txt (3.59 KB)
Your SOAP request looks good to me, it matches the out of the box policy that you are trying to use. It has the encryption and the signature elements in it. I am out of ideas at this point sorry could be of more help!
Akshith - the attached file was the soap request that I need to generate. Any idea how to create a policy to generate that, or should it happen out of the box. As you know we can’t see the request with security tag on the way out.
The SOAP request you shared should be generated using the X509Auth,encryption and signature out of the box policy in webMethods. You will need to set the keystore alias and key alias property along with partnerCert in the consumer WSD input under server Certs.
You should also add the partners cert to the webMethods truststore.
Thanks, I’ve done that and it’s not working. I’m at a loss as to what else to try.
I am on WM 9.6 and i have to add the wsse:security tag to the soap header. No encryption is needed and no certificates are exchanged and its a http call. How do i achieve this ? I tried to add the policy “Username_Signature” to the descriptor and provided user name and password, but that does not work. Below is what i need to add to the Soap Header. All that has to be sent is the username and password named “test” in the example below.
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soap:mustUnderstand="1">
<wsse:UsernameToken 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" wsu:Id="UsernameToken-1">