I implemented a webservice using WS-Security of digital certificate. I am using the WebSphere 5.1 studio so I see the generated ibm-webservices-bnd.xmi and ibm-webservices-ext.xmi two files contain this security integrity configuration. However the WSDL file itself seems has no change compared with the webservice with no-security.
I am wondering how would the webservice client know what kind WS-security he should enable and configure in his side to access my secured web service successfully? Since from WSDL, client won't see WS-security information.
I tried to create two seperate clients. One is with no security at all and the client won't be able to get any thing back from my digital signature enabled webservice. By monitoring with the TCP/IP server, I saw the client get the SOAP Fault with the FaultCode - FailedCheck and FaultString - The SOAP Body is not signed.
The other client I created with WS-Security of digital signature. I monitored this client and see it can successfully access my web service.
Should client just check the fault and decide which WS-Security to implement at his side? Or is there other stand way that the client know?
WS-Security came into existence after WSDL 1.1, and as such the two are independent of each other. I think this will change in WSDL 2.0, though. But for the time being, the client just has to know what security to use, and possibly work with exceptions like you suggest.
Ping & DNS - updated with new look and Ping home screen widget
Joined: Jun 14, 2005
For the static webservice(two party point to point), I can tell my client what kind of WS-Security I am using and he should also use the same WS-Security. But for the dynamic webservice which is published to UDDI, the client has no clue what WS-Security to use based on the WSDL, so he will have to count on the fault exception to decode what kind WS-Security to implement at his side? Is that too much for the client?
One of the promises of Web services is to be able to loosely couple the end points and allow the publishing of services in UDDI directories that can be discovered and invoked dynamically at run time. Unfortunately, at this point in the technology life cycle, the use of WS-Security in the SOAP message header prevents us from being able to do this. Today's Java to WSDL emitters are not yet able to handle the creation of WSDL documents that appropriately describe the WS-Security requirements. Plus, even if they could, at this stage, development tools such as WebSphere Studio Application Developer or Visual Studio .Net couldn't generate the proxies that handle the WS-Security aspects of the service.
As such, the developers of Web services in early 2003 will need to make a conscious trade-off here. When WS-Security is used, the service provider needs to either provide stubs/proxies which partners can invoke that handle the WS-Security portion of the message or manually communicate the WS-Security requirement of the Web service to their potential business partners and customers. For the WS-Security-based project described in this paper, proxies that properly sign the message and insert the WS-Security element into the SOAP data stream were created for Java technology, COM, and .Net clients. The next generation of Web services development tools from IBM and others should be able to handle the WS-Security elements of a Web service, but for now, developers need to understand that this is an achievable, but manual process.
This is where WS-SecurityPolicy, http://www-128.ibm.com/developerworks/library/specification/ws-secpol/ comes in. It allows the service provider to specify what kind of security constraints apply to their service. Thus, when a client is querying some registry for a service, in addition to getting the WSDL and endpoint location, it can get the security policy to figure out how it needs to secure the messages in order to be able to use that service.
Thanks for this interesting information. However, I still don't get it - Does the service provider need manually define the implemented security in such so called policy file? where is that file suppose be? When provider publish the WSDL to UDDI, does he need to do something else?
I am using WebSphere studio and when I specify that my service endpoint need the digital signature, the wizard automatically generate two IBM webservice extension files - ibm-webservices-bnd.xmi and ibm-webservices-ext.xmi. In those two files there are some security definition. But I don't see the client will get any information on those since those two files are on the service provider server side.
Is there any detailed resource / tutorial on those WS-policy file generation? I am kind of lost or confused.