Re: Re: message/transport level security [Re: SOAP streaming and faults, security everywhere and performanceimplications [Re: opinion Axis' future ... [Re: Using SAAJ-1.2 API tomodify the soap header/body content

[Samuel Meder <me...@mcs.anl.gov>]

On Wed, 2004-06-09 at 15:13, Davanum Srinivas wrote:
> I just browsed their code....No, they don't have WS-SecConv support as
> far as i can tell.

We ended up implementing our own equivalent (for timing and other
reasons). So no, we don't have WS-SecConv. From a protocol performance
perspective the issues should be exactly the same though.

/Sam

> 
> -- dims
> 
> On Wed, 09 Jun 2004 15:10:37 -0500, Aleksander Slominski
> <as...@cs.indiana.edu> wrote:
> > 
> > Davanum Srinivas wrote:
> > 
> > >Do you have a WS-SecConv impl? (open source?)
> > >
> > >
> > we looked on Globus Toolkit 3.2 which i think is an early/prototype
> > implementation and i am not sure about its long term status.
> > 
> > i am sure that Globus guys will have more definitve answer to that :)
> > 
> > thanks,
> > 
> > alek
> > 
> > 
> > 
> > >On Wed, 09 Jun 2004 11:15:58 -0500, Aleksander Slominski
> > ><as...@cs.indiana.edu> wrote:
> > >
> > >
> > >>Sanjiva Weerawarana wrote:
> > >>
> > >>
> > >>
> > >>>"Samuel Meder" <me...@mcs.anl.gov> writes:
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>I completely agree on Alex's point that security (and other QoS aspects)
> > >>>>are very important for us working in the Grid world. It is hard to
> > >>>>justify to users that turning on security will cause a 10x slowdown (it
> > >>>>is actually even worse with larger payloads) and since grid scenarios
> > >>>>are generally multi organization security is a ubiquitous requirement (I
> > >>>>would think that the same is true for B2B scenarios).
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>Of course. However, that's a fundamental issue with XML security
> > >>>and not with the WS-* specs in particular. The XML sec stuff is
> > >>>defined in terms of DOMs and DOM hash's .. which can be computed
> > >>>in a streaming model for many XPaths ..
> > >>>
> > >>>
> > >>>
> > >>>
> > >>hi Sanjiva
> > >>
> > >>i think that it is true for verification but not for signing as you need
> > >>to compute signature: you *can* compute it in a streaming fashion but
> > >>then you need to put signature in header so you have to buffer whole
> > >>stream output (why, oh why, there is no footer element in SOAP ...)
> > >>
> > >>
> > >>
> > >>>Furthermore using WS-Security without WS-Secure Conversation is
> > >>>retarded (IMO).
> > >>>
> > >>>
> > >>>
> > >>>
> > >>there are many cases to consider and each situation is unique.
> > >>
> > >>WS-SecConv does not buy you much if you do very coarse grained messaging
> > >>(only one message sent to service) still the overhead is small enough
> > >>that may be doable to do WS-SecConv for every message.
> > >>
> > >>however there is a potential scalability problem as server needs to
> > >>remember all those opened sessions so implementation must be very
> > >>careful here (we did some testing and in one test setup after a thousand
> > >>or so connections server refused to accept any new connections ...)
> > >>
> > >>
> > >>
> > >>>In summary,  IMO there's no reason why WS-Security/WS-Secure Conversation
> > >>>have to be any less performant than any other public key security
> > >>>technology IMO for many cases.
> > >>>
> > >>>
> > >>>
> > >>yes - if we do have better libs to do efficient
> > >>streaming/canonicalization/verification/signing and generally avoiding
> > >>excessive memory usage.
> > >>
> > >>
> > >>
> > >>>There may be degenerate cases where
> > >>>it is, but if we can make those rare then we're in business.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>that is still to be seen :)
> > >>
> > >>currently SSL without keep alive (so it does key exchange each time) is
> > >>2-5x faster than WS-SecConv after first message (this is just estimate
> > >>...) and SSL with keep alive (no key exchange so it is comparable to
> > >>session in WS-SecConv) it is faster by *order of magnitude* than
> > >>WS-SecConv in what we tested (caveat emperor!)
> > >>
> > >>plus with SSL you can  easily by hardware accelerator and load balancers
> > >>that will understand SSL it will take some time before WS-SecConv is
> > >>real standard and has this kind of support ...
> > >>
> > >>we are going to submit a paper (Satoshi did a great work on this) with
> > >>details on tests to Workshop on Grid Computing (Grid 2004) and hope that
> > >>it will lead to some discussion and ultimately faster (streaming?) code
> > >>in future :)
> > >>
> > >>thanks,
> > >>
> > >>alek
> > >>
> > >>--
> > >>The best way to predict the future is to invent it - Alan Kay
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> > 
> > --
> > The best way to predict the future is to invent it - Alan Kay
> > 
> > 
-- 
Sam Meder <me...@mcs.anl.gov>
The Globus Alliance - University of Chicago
630-252-1752