Hi, We've come up with a solution for our problems. But kindda looks like a hack. We need your blessing on this. ;-) Please see explanation attached.
On Thu, 24 Feb 2005 13:07:09 +0000, John Hawkins <[EMAIL PROTECTED]> wrote: > > We've recently looked into this area and it does not look easy to do :-( > > > > > Samisa Abeysinghe <[EMAIL PROTECTED]> > > 24/02/2005 11:18 > > Please respond to > "Apache AXIS C Developers List" > > > To Apache AXIS C Developers List <[email protected]>, Din%$h > <[EMAIL PROTECTED]> > > cc > > Subject Re: need to access Soap Body from Serializer > > > > > > Well I do not think we have a dom tree. :( We use SAX with a pull model. > > However, there are some issues raised in Jira to support what you are > looking for to support WS-Sec. It is not yet implemented though. > > Samisa... > > > > On Thu, 24 Feb 2005 02:02:08 -0800, Din%$h <[EMAIL PROTECTED]> wrote: > > Hi, > > When we doing encryption , We get a body as a string and parse > > it to DOM Document . > > > > Please correct me if I'm wrong , In axis engine we build a DOM Tree > > and then retrieve Headers and other wanted things as we want?? > > > > Is there a possibility to get access to DOM tree directly, If we able > > to get DOM Document directly that will be more efficient to perform > > encryption/decryption.rather than parsing string into DOM Document. > > > > U'r suggestions are warmly welcome !!! > > > > thanks > > regards, > > Dinesh > > > > -- Best regards, Sameera Perera
2.2 Current Issues with Digital Signature Implementation The ideal approach for integrating WSS4C (and thus WS-Security) into Axis C++ is to implement it as a Global Handler. This would effectively restrict the WSS4C accessible interface for the SOAP request/response to; 1. IHandlerSoapSerializer 2. IHandlerSoapDeSerializer Implications of this are: 1. WSS4C can only get/set the SOAP Body as a character or binary stream. If DOM like processing is required on the body, WSS4C itself has to utilize a third party XML DOM Parser to create such a DOM. The DOM so created, requires to be serialized by WSS4C again, before being released back to Axis. 2. Since the SOAP Header is not available as either a character or binary stream, WSS4C will not be able to construct a full DOM Document in this manner. These constraints, hinders the implementation of WSS4C in the following manner: 1. The WS Security specification allows for any element in the SOAP Body to be signed independently. A web service may require that the whole message Body be signed while another may only require a single element carrying sensitive information to be signed. Such selection is possible only through a DOM-like interface for the Body, which is not directly accessible through Axis. 2. The specification singles out detached Signatures as the only signature type to be used. While the specification does not dictate that the signature be added to the wsse:Security header block, it has been favored. In outflow conditions, where WSS4C is signing the SOAP message, the SOAP Header would need to be modified. In inflow conditions, where WSS4C is verifying the signatures, the SOAP header would need to be checked to obtain the required information. While Axis is fully capable of facilitating such interactions with the Header, problem suffices if when a fully XML Signature compliant library such as the Apache�s XSEC is used for signing and verification. Such libraries, keeping with the XML Signature Proposed Recommendation (http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/) would try to insert such header information themselves. Since, this header information is exactly what we need to included in the WSS compliant signed envelope, we�d probably have to recreate them using the Axis API. Considering factors such as efficiency and server loading we have come up with several alternative approaches for the implementation of WSS4C. The following section outlines the most promising one among them. To build up a DOM Document the following (pseudo-coded) method may be adopted. soap_body_string = GetBodyAsString() soap_message_string = �<SOAP-ENV:Envelope xmlns:SOAP-ENV=\��\�><SOAP-ENV:Body>� + soap_body_string + �</SOAP-ENV:Body></SOAP-ENV:Envelope>� DOM_document = parseToDOM(soap_message_string) Now, using XSEC::DSIGSignature we could easily apply a XML Digital Signature to this DOM. However, this would generate a large number of header information inside <SOAP-ENV:Header> that we are unable to send back to Axis (unless of course, we recreate them using the serializer). Therefore we could simply re-implement DSIGSignature�s signing logic inside our handler replacing all calls to modify <SOAP-ENV:Header> with corresponding calls to the IHandlerSoapSerializer. The Digital Signature verification too may proceed in a similar manner. While effectively cutting down the amount of parsing that is required at the handler level, this approach still cannot circumvent the problem of having to reparse a SOAP request that Axis has already parsed using its SAX based pull parser. However, considering that Axis would actually be parsing the SOAP headers only, with the body being simply retrieved, argument may be made that we are not reparsing already parsed information.
