Return-Path: Delivered-To: apmail-ws-axis-c-dev-archive@www.apache.org Received: (qmail 12683 invoked from network); 20 Dec 2004 10:20:45 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 20 Dec 2004 10:20:45 -0000 Received: (qmail 69542 invoked by uid 500); 20 Dec 2004 10:20:43 -0000 Delivered-To: apmail-ws-axis-c-dev-archive@ws.apache.org Received: (qmail 69505 invoked by uid 500); 20 Dec 2004 10:20:42 -0000 Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: List-Id: "Apache AXIS C Developers List" Reply-To: "Apache AXIS C Developers List" Delivered-To: mailing list axis-c-dev@ws.apache.org Received: (qmail 69472 invoked by uid 99); 20 Dec 2004 10:20:42 -0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=FORGED_RCVD_HELO,HTML_20_30,HTML_MESSAGE,HTML_TITLE_EMPTY,USERPASS X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from mail.opensource.lk (HELO squid.cmb.ac.lk) (202.51.147.3) by apache.org (qpsmtpd/0.28) with ESMTP; Mon, 20 Dec 2004 02:20:37 -0800 Received: from [10.2.6.135] ([203.94.74.174]) by squid.cmb.ac.lk (8.12.9/8.12.9) with ESMTP id iBKARK8Z080121 for ; Mon, 20 Dec 2004 16:27:24 +0600 (LKT) (envelope-from susantha@opensource.lk) Message-ID: <41C6A762.1070500@opensource.lk> Date: Mon, 20 Dec 2004 16:20:18 +0600 From: Susantha Kumara Reply-To: susantha@opensource.lk Organization: Lanka Software Foundation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Apache AXIS C Developers List Subject: Re: need to access Soap Body from Serializer References: <7f041d43041217070745e33fcf@mail.gmail.com> <7f041d430412181736148468d@mail.gmail.com> In-Reply-To: <7f041d430412181736148468d@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------080608060609020101090908" X-Virus-Scanned: by amavisd-new X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N This is a multi-part message in MIME format. --------------080608060609020101090908 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sameera Perera wrote: >Hi John, > >Thank you for your interest. > >The handler (if used) would reside on both sides (client & server). >It should process all incoming SOAP requests and perform decryption and >signature verfication and all out going SOAP request and perform encryption >and signing. >Ideally there would be an API which the webservice author can use to specify >which parts should be encrypted/signed, whether to ommit this process altogether >etc. But for now, we are just concentrating on a more static approach (e.g. WSDD >settings). > >The reason for the Xerces DOM is that we are using the Apache XML >Security library > >(XSEC),which only works with Xerces DOMs. Since it already supports >XML encryption, > >signatures, OpenSSL X.509 certificates etc. the library has saved us a >lot of work. > >Right now, the easy way to keep everything in place is to reparse the >entire SOAP > >message inside our handler onto a Xerces DOM and proceed. Which might not be the >most efficient way of going about it. >This is where the surrogate DOM might seem a good idea.We can fool the >XSEC to think that its working with a Xerces DOM, provided that this >would be enabled > >by Axis. That way Axis can keep supporting Expat and any other parser. > >Best regards, >Sameera. > > > >On Fri, 17 Dec 2004 17:06:46 +0000, John Hawkins wrote: > > >>Hi Sameera, >> >>before we debate this could you give us a better idea of the model you are >>using here please? >>E.g. >>Are we in a handler on the client-side here or server or both, >>Are we in a handler at all? >>Why does it require Xerces DOM? Does this mean we could never support >>expat? >> >>thanks, >>John. >> >>John Hawkins >> >>Sameera Perera wrote on 17/12/2004 15:07:34: >> >> >> >>>Hi all, >>> >>>I'm working along side Dinesh on the implementation of WS-Security >>>for Axis C++. >>>To avoid a lot of reimplementation we are using Apache's XML-Security >>>libraries which >>> >>>require that we give it a Xerces DOM to work with. >>> >>>However, at present Axis is only giving us, a serialized header block >>>and a string >>>representation of the SOAP body. Option open to us is to combine thetwo >>> >>> >>into a >> >> >>>memory stream and let Xerces parse it into a DOM. Obviously, this >>> >>> >>requires an >> >> >>>expensive reparsing of the SOAP message. >>> >>>The 2 alternatives that I see are; >>>1. >>>Implement the XMLParser interface (as described in ___dev-guide.html >>>in Axis C++ >>>docs). >>>Parse the AxisIOStream to a Xerces DOM. >>>Perform encryption/decryption, signing/verification >>>Mimic the rest of the interface methods using the DOM >>> >>>2.(Uses Proxy (Surrogate) design pattern. Also requires that the SOAP >>> >>> >>body is >> >> >>>available through the serializer). >>>Inherit a new class from Xerces DOM. >>>Override all its public methods to call mehtods offered by Axis. >>>Using a handler get the SOAP message through the serializer. >>>Pass the surrogate DOM to the XSEC library (all function calls on the >>>DOM will now be >>>rerouted to Axis) etc. >>> >>>Right now, none of the 3 seem very attractive. Any suggestions will be >>> >>> >>much >> >> >>>appreciated. >>>Thanks. >>> >>>Best regards, >>>Sameera. >>> >>> >> >> > > > > Hi Sameera, IMO there is another alternative. That is to implement AxisIOStream interface as an stream intercepter and use it to do the job. I think Axis Handler API can be improved to provide a mechanism to dynamically register a stream intercepter that will operate between the transport and parser and do the job. Then if your handler (XSEC handler) is in operation it will first register this intercepter and wait. When there is a stream (both incoming and out going) your handler will be called and given opportunity to do these security operations on the stream (enc/dec/signing etc). BTW is there any clue of a future XML security library that operates on pull/push/reparse rather than DOM ?. Or is it theoretically impossible ?. Susantha. --------------080608060609020101090908 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sameera Perera wrote:
Hi John,

Thank you for your interest.

The handler (if used) would reside on both sides (client & server).
It should process all incoming SOAP requests and perform decryption and
signature verfication and all out going SOAP request and perform encryption
and signing. 
Ideally there would be an API which the webservice author can use to specify
which parts should be encrypted/signed, whether to ommit this process altogether
etc. But for now, we are just concentrating on a more static approach (e.g. WSDD
settings).

The reason for the Xerces DOM is that we are using the Apache XML
Security library

(XSEC),which only works with Xerces DOMs. Since it already supports
XML encryption,

signatures, OpenSSL X.509 certificates etc. the library has saved us a
lot of work.

Right now, the easy way to keep everything in place is to reparse the
entire SOAP

message inside our handler onto a Xerces DOM and proceed. Which might not be the
most efficient way of going about it.
This is where the surrogate DOM might seem a good idea.We can fool the 
XSEC to think that its working with a Xerces DOM, provided that this
would be enabled

by Axis. That way Axis can keep supporting Expat and any other parser.

Best regards,
Sameera.



On Fri, 17 Dec 2004 17:06:46 +0000, John Hawkins <HAWKINSJ@uk.ibm.com> wrote:
  
Hi Sameera,

before we debate this could you give us a better idea of the model you are
using here please?
E.g.
Are we in a handler on the client-side here or server or both,
Are we in a handler  at all?
Why does it require Xerces DOM? Does this mean we could never support
expat?

thanks,
John.

John Hawkins

Sameera Perera <www.sumudu@gmail.com> wrote on 17/12/2004 15:07:34:

    
Hi all,

I'm working along side Dinesh on the implementation of WS-Security
for Axis C++.
To avoid a lot of reimplementation we are using Apache's XML-Security
libraries which

require that we give it a Xerces DOM to work with.

However, at present Axis is only giving us, a serialized header block
and a string
representation of the SOAP body. Option open to us is to combine thetwo
      
into a
    
memory stream and let Xerces parse it into a DOM. Obviously, this
      
requires an
    
expensive reparsing of the SOAP message.

The 2 alternatives that I see are;
1.
Implement the XMLParser interface (as described in ___dev-guide.html
in Axis C++
docs).
Parse the AxisIOStream to a Xerces DOM.
Perform encryption/decryption, signing/verification
Mimic the rest of the interface methods using the DOM

2.(Uses Proxy (Surrogate) design pattern. Also requires that the SOAP
      
body is
    
available through the serializer).
Inherit a new class from Xerces DOM.
Override all its public methods to call mehtods offered by Axis.
Using a handler get the SOAP message through the serializer.
Pass the surrogate DOM to the XSEC library (all function calls on the
DOM will now be
rerouted to Axis) etc.

Right now, none of the 3 seem very attractive. Any suggestions will be
      
much
    
appreciated.
Thanks.

Best regards,
Sameera.
Hi Sameera,

IMO there is another alternative. That is to implement AxisIOStream interface as an stream intercepter and use it to do the job. I think Axis Handler API can be improved to provide a mechanism to dynamically register a stream intercepter that will operate between the transport and parser and do the job. Then if your handler (XSEC handler) is in operation it will first register this intercepter and wait. When there is a stream (both incoming and out going)  your  handler will be called and given opportunity to do these security operations on the stream (enc/dec/signing etc).

BTW is there any clue of a future XML security library that operates on pull/push/reparse rather than DOM ?.  Or is it theoretically impossible ?.

Susantha.
--------------080608060609020101090908--