Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@xml.apache.org
Importance: Normal
Subject: Re: Pass-Through Axis Nodes
To: axis-dev@xml.apache.org
Message-ID: <OF4D3AC514.A86F1341-ON49256A0E.0004140C@LocalDomain>
From: "Yuhichi Nakamura" <NAKAMURY@jp.ibm.com>
Date: Tue, 13 Mar 2001 09:55:20 +0900
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii


Hi Pawel,
Your problem can be solved in the current Axis architecture.
Some Axis nodes can be intermediaries.
BTW, do we have intermediary samples in the cvs tree?

Comments in line:

>Gentlemen,
>I am currently exploring the ways to protect my web services
communications
>from unauthorized access, spying eyes and bulkiness of the messages. There
are
>few solutions already on the net - like Digital Signature extension from
IBM
or
>simple authentication in Axis. They seem however to be very basic
considering
>the potential requirements for the data being sent.
Digital Signature and basic authorization (SSL-based) are a good starting
point.
I guess.

>The chaining concept presented in the Axis architecture document would be
>perfect to employ certificate based authentication, non-repudiation, etc.
There
>is a problem however with the client side where the chain elements to e.g.

>encrypt message are missing. The digital signatures demo from IBM solves
the
>problem using a special SOAP service to wrap the original message but that
does
>not provide an elegant chaining solution. The nice solution would be to
have,
>except Axis end-nodes, Axis pass-through nodes. Those nodes would serve
for
>example as gateways for communication out of the company. The additional
bonus
>would be an ability for strong enveloping - user would use SSL to send the

>request to the nearest pass-through node. Leaving the node the SOAP packet
may
>be wrapped multiple times in the intermediate nodes for other purposes,
for
>example separate encrypted and signed POs may be bundled in one message.
On
the
>receiving side a similar node would route the requests or their parts to
the
>respective departments.
We should have digital signature handler, basic authentication handler,
encryption
handler, etc.  They can be placed in ANY Axis nodes, including
intermediaries.

>I have tried to use existing framework to develop the pass-through nodes
but
>there is a problem with the early deserialization. The wrapping services
>usually know nothing about the wrapped content except it is xml compliant.

>That
>would require either keeping the content in xml or using fake
>serializers/deserializers to wrap the content into java classes. While the

>latter is possible to do it may however interfere with deployment tools in
the
>future.
>As of the question in the doc if the messages should serialize/deserialize

>themselves or use external classes I think the external classes are a
better
>solution. For now I am able to create services with quite complex
interfaces
>using the Castor generated classes (http://castor.exolab.org/) . After
creating
>the xml schema for the message it takes literally minutes to have the
shell for
>the services with all the serializing/deserializing classes generated. It
would
>be however difficult to integrate Castor with Apache SOAP should the type
info
>mapping require separate serializer/deserializer for each of the types
mapped.
You mean "current Axis."  If you report your problem in more details, some
of Axis
members will take a look at it.  I feel that serialization/deserialization
is independent
of security issues.  If you addressed "message" instead of "rpc", would you
still
have the security issue?

>Do you think the existing Axis architecture may be extended to accommodate

>pass-through processing as well ?
Yes.

>Best regards,
>Pawel.
>

Yuhichi Nakamura
IBM Research, Tokyo Research Laboratory
Tel: +81-46-215-4668
FAX: +81-46-273-7428