Since Axis C++ needs an object model why not port AXIOM which is been used with Axis2 to C++ and get the ecoding support completed in Guththila (the C++ pull parser).
Porting OM will not be a problem if someone can help with getting encoding support in the pull parser fixed. Regards, --Dasarath --- Sameera Perera <[EMAIL PROTECTED]> wrote: > 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. > __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/
