axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <...@us.ibm.com>
Subject Re: Signed SOAP messages & handling secuirty
Date Thu, 26 Apr 2001 18:42:29 GMT
You pass state information thru the use of the 'bag' in the
message context.  Any handler can put whatever it wants in
there and any other handler can then use it.
-Dug


David Melgar/Raleigh/IBM@IBMUS on 04/26/2001 02:39:44 PM

Please respond to axis-dev@xml.apache.org

To:   axis-dev@xml.apache.org
cc:
Subject:  Re: Signed SOAP messages & handling secuirty



As far as I know, the intent is not to include signed messages as part of
Axis. The intent of the TRL proposal was to illustrate the use of handlers
in Axis.

I'm working on an axis handler using xss4j that signs and verifies
signatures.

I've also had questions as you indicate about how to pass state information
between handlers. A signature verification handler is an interesting
example. Currently, it requires the incoming message to contain a valid
signature. The user can control this requirement by setting up the
appropriate chain, so it could be specific to one service or global.

However, ideally, it seems desirable to let the service make the decision
whether or not to accept the message. Maybe its ok depending on the
specific request to accept an unsigned message. Maybe identity information
would be useful to the service.

It appears the current Axis design allows (as you said) the handler to
modify the message to add information the service could use. Interesting
idea.  Ideally, it should be placed somewhere generic, not dependent on the
specific service being called, not as another parameter to the call, but
maybe a special header, as long as the method can go through some process
to get to the information.

Another area of debate is how security requirments for a web services
should be represented in wsdl. How can I tell if a service requires signed
or encrypted messages and responses signed or encrypted.



James Casbon <James.Casbon@citria.com> on 04/26/2001 10:37:24 AM

Please respond to axis-dev@xml.apache.org

To:   "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
cc:
Subject:  Signed SOAP messages & handling secuirty




I saw with interest the TRL proposal in the nightly build I downloaded.  Is
the intention to include signed messages as part of Axis?

If it is to be included, it seems strange to base this on xss4j for two
reasons:

xss4j is not open source & requires license fee
xss4j does not allow for integration with cryptoki (and cannot be modified
as it is not open source).

Further, the Signature class currently only allows for the attachment of
one
certificate.  Should it not offer a way of including an entire certificate
chain for trust verification?

I also cannot see anything in the SOAP specifications that details how
security is to be handled.  I mean, to offer a secure RPC handler would you
chain to handlers: have a security handler and a rpc handler and let the
security handler verify a call?

Consider a banking service that offers a transfer method.  The user makes a
call to a method such as:

     makeTransfer( int sourceAccount, int destinationAccount, float
funds);

he then signs the call to indicate he is authorised to transfer from the
source account and posts the SOAP message

The message arrives at the server, and the security handler verifies his
digital signature.  What we need now is a standard way of including this
identity so that it is accessible by the method being invoked.  One
possible
way would be to have the Security Handler insert the verified identity as a
parameter to the method call, and I have successfully applied this approach
to Apache SOAP 2.1.  But this does seem an arbritrary convention, is there
a
better way?

thanks,


James


James Casbon
Software Engineer
Citria Ltd
40 Holborn Viaduct
London EC1N 2PB
United Kingdom

T: 020 7832 3185
M: 07968 055943
F: 020 7832 3232
E: James.Casbon@citria.com
Citria Limited <http://www.citria.com>

__________________________________________________________________

If you are not the addressee of this confidential e-mail and any
attachments, please delete it and inform the sender; unauthorised
redistribution or publication is prohibited.
Views expressed are those of the author and do not necessarily
represent those of Citria Limited.
__________________________________________________________________





Mime
View raw message