axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sedukhin, Igor" <>
Subject RE: Today's IRC log (about security)
Date Wed, 09 Jan 2002 15:39:45 GMT

Things like wsdl compilers, authentication handlers, etc. are already part of Axis. If it
was just for pure SOAP messaging, then only a very small subset of Axis is needed. It appears
that Axis is becoming a good open-source Web Services framework, which probably could not
ignore security implications.

Leaving security out of scope, wouldn't it diminish the value of work that has already been
done on the Axis?

Xml-security does not have to become part of Axis, but it may make sense to drop in few classes
to *extend* Axis and facilitate security header assembly/interrogation.

The client side bugs me more than the server side really. If I wanted to use Axis to make
a secure service invocation, and have to assemble whole msg in DOM... I doubt it would be
acceptable, and in that case it would be better to opt for GLUE or something...

-- Igor Sedukhin .. (
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788

-----Original Message-----
From: James M Snell [] 
Sent: Tuesday, January 08, 2002 7:34 PM
Subject: RE: Today's IRC log (about security)

Comments inline...

These comments represent my personal opinion

- James M Snell/Fresno/IBM
    Web services architecture and strategy
    Internet Emerging Technologies, IBM
    544.9035 TIE line
    559.587.1233 Office
    919.486.0077 Voice Mail =================================================================
Have I not commanded you?  Be strong and courageous.  Do not be terrified, 

do not be discouraged, for the Lord your God will be with you wherever you 
- Joshua 1:9

Please respond to 
Subject:        RE: Today's IRC log (about security)

>As I was writing my note to Christian, I noticed that Dims is also 
some serious fun :) with signing SOAP messages with Axis and xml-security. 
I'm not >sure who else is concerned about this, but would be very 
interesting to find out.
>It certainly does not look pretty with Axis right now, but before any
modifications are done, I suggest to have a little conceptual discussion 
take place. To be >more specific:
>1. Should Axis implement SOAP-SEC or WS-Security or both? WS-Security
seems to cover authentication/authorization as well as 
integrity/encryption. It also >seems more extensible.

Neither.  Axis should provide an easy means of manipulating envelopes and 
dispatching requests period.  SOAP-SEC and WS-Security are outside the 
scope of Axis. 

>2. This is not part of any JSR yet. It certainly eventually is going to
be there. Insiders, any clue... 
>3. Axis can be extended with SOAPSecurityHeader derived from SOAPHeader
with additional methods to take care of SOAP-SEC or WS-Security 

This should not be done as part of Axis proper. 

>4. XML-Security can be integrated into Axis to handle
integrity/encryption. Handlers can be written for sign, verify, encrypt 
and decrypt. These handlers can be >deployed on clients and servers to 
facilitate processing. It would be up to the application to chain them 

Again, these should not be done as part of the core Axis deliverable.

>5. Handlers can be written to extract credentials form the SOAP message
and do the auth check. Very much like HTTPAuthHandler does now, only that 
>identity comes from the message and not from HTTP session.
>To me it appears very important to get it right with Axis. It is all
about convenience and interoperability. Very few people would be happy 
with purely >Axis-to-Axis operations or working with DOM elements to 
assemble message headers.

The most important thing to get right with Axis is the message 
manipulation API and message handling.  SOAP-SEC, WS-Security and XML 
Security are orthogonal, separate components that should not be part of 
the main Axis codebase.

>-- Igor Sedukhin .. (
>-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788 

View raw message