Currenly I have develop and configure my flow service became web services enable, so from third party application can invoke my flow service usiang SOAP RPC. but how to implement WS Security (Encription form my message input).
The short answer is the Integration Server doesn’t support ws-security. I believe Mark C. can jump in here and talk about some stuff he has done with a custom soap processor within the Integration Server to try and use ws-security. We would like to see the IS server support the WS standards but that is a ways out. ServiceNet is the current product supporting the WSF set of standards.
Well, the story is not necessarily “bad news”, but it’s certainly a mixed bag.
First, a bit about your requirements. You stated that you need to support soap-rpc style messages AND web services security. That might be a particularly difficult thing to do in Integration Server, because IS doesn’t support working with the soap headers of soap-rpc style messages. But before we get into how you might go about addressing that, you should be really, really sure that you’re understanding the requirement correctly.
The state of the market and the best practices for building interoperable web services as described by the Web Services Interoperability (WS-I) Basic Profile 1.0 and WS-I Basic Security Profile 1.0 would not lead to the combination of soap-rpc and WS-Security. Not that the two can’t be combined, but that it is less well-accepted and less interoperable to do so. (See these posts from an earlier thread today for more thoughts on WS-I Basic Profile)
So assuming that you are being asked to support WS-S using soap-rpc messages, how can you do this in Integration Server 6.x? I would start by creating a custom soap processor that handled soap rpc messages. As covered elsewhere in this forum, custom soap processors are just Flow or java services that intercept a soap message after the content handler processes it but before the target service is invoked. With document/literal services this is the perfect place to put “out-of-band” processing of soap header elements like the ones required to support WS-Security.
What you’ll have to find out is whether you can do something similar with soap-rpc messages. If you can’t do this as a custom soap-rpc processor you’ll have to back up a layer and determine if there is a way to replace the soap-rpc content handler. Before doing that I would probably examine other options such as implementing webMethods ServiceNet 6.5 to act as an intermediary that could process the soap-rpc messages and process the security tokens in the header to perform the required authentication and authorization tasks before IS ever receives the message.
So, in summary, the combination of soap-rpc or more specifically rpc/encoded style and WS-Security is uncommon, non-conformant to WS-I Security and not well supported by many tool vendors (including Microsoft Visual Studio .Net). You will find this difficult to do easily or, perhaps, even at all using Integration Server and Developer 6.5 or earlier. Another good option may be to deploy ServiceNet 6.5 as an intermediary “upstream” from Integration Server.
It is much easier to support WS-Security 1.0 using document/literal or soap-msg style soap messaging.
You need to create a custom soap processor that will receive incoming soap requests and process the wsse:Security headers before invoking your service. Other posts in this forum describe the functions that a custom soap processor needs to perform.
The XML Encryption and XML Digital Signature specs are not supported today by Integration Server. It should be possible to support by developing services that provide the encrypt/decrypt and sign/verify signature functions.
Before attempting to write this yourself, I would seek out someone in your organization who understands these specifications well and can guide you as you attempt to build support for them into IS. In other words, this is an advanced-level task and requires an advanced-level knowledge of XML schema, public key encryption and web services.
If you think that it should not be this hard to support WS-Security 1.0 in Integration Server… you are right.
A possible alternative, as I mentioned in my earlier post, you can implement the just released webMethods ServiceNet 6.5 as a web services intermediary in your architecture. SN 6.5 does claim support for WS-Security 1.0 including XML Encryption and XML Digital Signature. It would receive messages to be routed to IS and perform the required security functions (authentication, authorization, XML decryption, XML signature verification) before the message is sent on to IS.
Diagram of webMethods ServiceNet as an intermediary “upstream” of the web services provider is attached.
In this role, ServiceNet can provide the functions of WS-Security (decryption, signature verification and authentication) before the web services consumer receives the message.
The ServiceNet User’s Guide is available on webMethods Advantage.
Thank you for your response. would you give me a link or sample how to do custom soap processor. I can’t implement servicenet because i used is 6.1 and don’t have licensed for servicenet 6.5.
Is it common to implement if i just encript my xmlstring input using like bouncy castle pgp implementation and send through normal soap-rpc “encripted message” and when the flow service receive that message, just decript the xmlstring and processed ?
Glue is a soap toolkit obtained as part of the
acquisition of The Mind Electric. It can be deployed into J2EE application servers to expose EJBs as web services or standalone to expose plain ole java applications (POJOs) as web services.
It is possible to “embed” Glue into Integration Server to provide some soap functionality such as Soap With Attachments (SWA). However, doing so is difficult to configure and hard to support.
Hi,
I have an urgent requirement of invoking external customer’s webService using SOAP-HTTP. But we need to digitally sign and encrypt using X509 Certificates and then verify and decrypt the SOAP response.
We want to achieve this using IS 6.1. We do not have license for ServiceNet or Glue of wM 7.0
Any help in this regard is highly appreciated.
This can be achieved using IS 6.1 and by coding java services which access methods in third-party XML encryption and digital signature libraries. The design tradeoffs come in deciding how much of the message to encrypt and / or sign as attempting to do so on large portions of very large messages can result in poor performance as the entire portion to be signed and / or encyrpted must be read into memory.
WS-Security requires adding binary tokens as elements in soap headers. As these tokens are merely XML strings, IS is well-suited to building them if their structure is well understood and if the libraries needed to sign, encrypt or add the authentication conent are readily available.
Hi Mark,
Thanks for your inputs.
It would be of great help to me if you could provide sample code for doing this or atleast steps that need to be followed to achieve this.
I really appreciate your help.
First, read through the examples here on custom document / literal soap processors. When you have that figured out, then work out how to add the most basic UsernameToken into the header of an outbound soap request (or read one from an inbound soap request).
Now your ready to tackle XML encryption and digital signature. Google will lead you to a number of libraries written to assist with this. If you get the provided examples working to encrypt and sign the simple strings, you’ll be ready to attempt to do so on single elements of a soap message or on the entire message.
I spent the better part of a week doing this before our requirements changed and it became unecessary for our project. I decided that it was achievable but painful. The most effort was going to be required to build a utilty service to encrypt / decript and sign / verify signature of a given XML string.
Hi Mark,
Thanks for your inputs, I did search on net and I could find that are open source jar files(apache) avaiable which can digitally sign and encrypt the SOAP message. I even tried running some of the samples but I am getting error various errors such as the following one and I am stuck. Sorry, I am not a Java expert and its taking me lot of time to debug such type of errors. It would really help me a lot if you have some ready samples which can sign and encrypt SOAP request Message. I really appreciate your help in this regard.
Exception in thread “main” java.lang.NullPointerException
at org.apache.xml.security.algorithms.implementations.SignatureDSA.engin
eInitSign(Unknown Source)
at org.apache.xml.security.algorithms.SignatureAlgorithm.initSign(Unknow
n Source)
at org.apache.xml.security.signature.XMLSignature.sign(Unknown Source)
at SignExample.main(SignExample.java:93)
I do not have any examples to share. Unfortunately, implementing XML digital signature and XML encryption in IS requires coding more advanced java services.
Hi Mark,
You are right. Since past few days, I have been researching on this and it looks like a difficult task of writing Java Services.
I have also opened ticket with webMethods, still waiting for their response.
I have read in the forum/advantage site that GLUE can be used for digital signature and encryption using X509 Certificates and Glue can be hosted on IS 6.1. I have following queries:
How stable is Glue hosted on IS 6.1?
Any known issues?
I have created the wsdl connector in IS which creates the SOAP Request Message, how do I invoke/call Glue to do the XML digital signature and encryption?
Glue can be embedded into Integration Server and I believe there are documents available either on Advantage or from WM Support to assist with this.
That said, I’m pretty sure this would still require custom coded java classes in Glue or in IS.
Bottom line, XML dig sig and encryption is not supported in Integration Server without advanced custom coding today. Help should be just around the corner with IS 7.1, but that doesn’t do you much good today.
Hi Mark,
Thanks for your inputs.
I was thinking if we can use an external Java Component, wM will pass the XML and invoke this Java Component. The Java Component will then digitally sign, encrypt and call the external webService.
This Java Coponent can either be exposed as webService or as an Servlet.
Pl advise if we can go ahed with this approach. Is there any other ways of invoking the Java Component.